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
