Re: [x32] PATCH: PR middle-end/47725: [x32] error: unable to find a register to spill in class DIREG

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Thu, Mar 17, 2011 at 9:00 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Thu, Mar 17, 2011 at 5:30 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Tue, Feb 15, 2011 at 2:55 PM, Bernd Schmidt <bernds@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.