Re: [Patch, AVR]: Fix PR46779

[Hans-Peter Nilsson <hp@bitrange.com>]

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.)

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."

> 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.)

> 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. :)

brgds, H-P