This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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


which is not uncommon code.

Thanks, Eric


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]