Re: [Patch, AVR]: Fix PR46779

[Georg-Johann Lay <avr@gjlay.de>]

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 <avr@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