On Wed, 22 Jun 2011, Georg-Johann Lay wrote:
> Hans-Peter Nilsson schrieb:
> > On Mon, 13 Jun 2011, Georg-Johann Lay wrote:
> >> [In CCing Richard Henderson]
> >> Denis Chertykov schrieb:
> >>> 2011/6/10 Georg-Johann Lay <a...@gjlay.de>:
> >
> >>>> Then I observed trouble with DI patterns during libgcc build and had
> >>>> to remove
> >>>>
> >>>> * "zero_extendqidi2"
> >>>> * "zero_extendhidi2"
> >>>> * "zero_extendsidi2"
> >>>>
> >>>> These are "orphan" insns: they deal with DI without having movdi
> >>>> support so I removed them.
> >>> This seems strange for me.
> >> As far as I know, to support a mode a respective mov insn is needed,
> >
> > For the record, not in general, just if you have patterns
> > operating on DImode. I.e. if you always have to call into
> > libgcc for every operation, you're fine with just SImode, as the
> > access will be split into SImode accesses. (That reload can't
> > split the access is arguably a wart.)
>
> For avr it's actually split in QImode (word_mode), SImode would be
> more efficient.
>
> > It's even documented, "node Standard Names" for mov@var{m}:
> > "If there are patterns accepting operands in larger modes,
> > @samp{mov@var{m}} must be defined for integer modes of those
> > sizes."
>
> Thanks for pointing that out.
>
> For avr that means: There is movsf pattern that is implemented less
> efficient than movsi. So removing movsf could improve code a bit.
> Besides efficiency, code for movsi and movsf can be the same on avr.
>
> >> which is
> >> not the case for DI. I don't know the exact rationale behind that
> >> (reloading?),
> >
> > Yes. (I ran into problems with this myself long ago.)
>
> So the zero_extend*di2 pattern are bogus because there is no movdi.
>
> >> just read is on gcc list by Ian Taylor (and also that it is
> >> stronly discouraged to have more than one mov insn per mode).
> >
> > That is correct.
> >
> >> So if the requirement to have mov insn is dropped and without the burden to
> >> implement movdi, it would be rather easy to implement adddi3 and subdi3 for
> >> avr...
> >
> > Resist the temptation... I see you did. :)
>
> The preferred handling is still that optabs cared for calling __adddi3
> if there is no adddi3 pattern... The target would have to care for
> implementing __adddi3 so generic libgcc need not to be changed and IMO
> changing libgcc for that would not be adequate.
>
> Johann
>
> > brgds, H-P
>
