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 <[email protected]>:
>
>>>> 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
