On Thu, Mar 17, 2011 at 9:00 PM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Thu, Mar 17, 2011 at 5:30 PM, H.J. Lu <hjl.to...@gmail.com> wrote: >> On Tue, Feb 15, 2011 at 2:55 PM, Bernd Schmidt <ber...@codesourcery.com> >> wrote: >>> On 02/14/2011 08:46 PM, Eric Botcazou wrote: >>>>> I agree with Jeff that combine would be the correct place to fix this. >>>>> At least it takes class_likely_spilled_p into account, so it will >>>>> restrict only those machines where extending the lifetime of hard regs >>>>> is dangerous. >>>> >>>> OK, but I don't see how copying to a new pseudo would interfere with that. >>> >>> For one thing, the set no longer matches the REG_EQUIV note we make >>> here, and that does seem to interfere with the optimization. I've tested >>> both patches on ARM, -march=armv7-a. The combiner patch produced no code >>> changes. The function.c patch produced regressions (increased register >>> pressure). Both results are as expected. >>> >>> To put it another way: the combiner change is conservatively correct, >>> and necessary if we're going to have extends of hard registers in the >>> RTL. The function.c change is demonstrably incorrect as shown by the ARM >>> codegen regressions. >>> >> >> I checked in my patch into trunk. >> > > I noticed that for x32, all pointers passed in registers are zero-extended > by caller. If we can fix > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48085 > > by avoiding zero-extension in callee, this issue won't happen for x32. I will > revert the combine change for now and try to implement this approach. >
The issues are 1. When passing a 32bit integer parameter in a register, hardware always zero-extends it to 64bit. I can update x32 psABI to document it, which costs nothing to implement in GCC. 2. assign_parm_setup_reg zero-extends 32bit pointer in register to 64bit, which is redundant. It leads 2 problems: 1. Redundant zero-extension at function entry. 2. combine doesn't check zero-extension on hard register and leads to internal compiler error. Is there a way to avoid redundant zero-extension at function entry to solve both problems? Thanks. -- H.J.
