Re: [Patch,AVR] Fix PR46278, Take #3

[Georg-Johann Lay <avr at gjlay dot de>]

Weddington, Eric a écrit:
> Georg-Johann Lay wrote:
> > This is yet another attempt to fix PR46278 (fake X addressing).
> >
> > After the previous clean-ups it is just a small change.
> >
> > caller-saves.c tries to eliminate call-clobbered hard-regs 
> > allocated to pseudos around function calls and that leads to
> > situations that reload is no more capable to perform all requested
> > spills because of the very few AVR's address registers.
> >
> > Thus, the patch adds a new target option -mstrict-X so that the 
> > user can turn that option if he like to do so, and then
> > -fcaller-save is disabled.
> >
> > The patch passes the testsuite without regressions. Moreover, the 
> > testsuite passes without regressions if all test cases are run with
> > -mstrict-X and all libraries (libgcc, avr-libc) are built with the
> > new option turned on.
>
> Hi Johann,
>
> But if all test cases pass with running -mstrict-X and everything 
> built with that option on, then why is this even an option? Is it 
> because that it may not always reduce code size?...

As with any other optimization, I'd guess yes.

But the major problem with this patch -- or any patch that addresses 
this PR -- is that taking away the X+const addressing might render the 
challenge of register allocation for AVR to a too big one so that reload 
cannot cope with it any more and ICEs with spill failure.

Denis' analysis showed that the root cause of these spill fails is that 
there is just one register that can perform R+const addressing besides 
FP but that register (Z) is call-clobbered.  Dunno if these problems 
were also triggered by caller-saves.  Thus, if some real world code 
breaks with a spill fail, the option provides a fallback to cure 
reload's shortcomings.

It's just a kludge, of course, but trying to fix reload is nothing I 
would do (I know my limits) and the prospects are thin that a target as 
unimportant as AVR will draw attention of some reload expert.

But looking at the results, I think it's worth it. 30% less for an 
already optimized program is not bad -- or the other way round: 50% 
bloat without this option is horrible.  And these test programs are not 
fancy; they are just accessing struct components via

    pstruct->component

which is not uncommon code.

> Thanks, Eric

Johann