PATCH: PR middle-end/47383: ivopts miscompiles Pmode != ptr_mode

Richard Guenther richard.guenther@gmail.com
Thu Feb 10 16:31:00 GMT 2011


On Thu, Feb 10, 2011 at 3:41 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Thu, Feb 10, 2011 at 2:18 AM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>
>>>>
>>>> By combined brain-power we dug out the last sentence of 3.3.7
>>>> of the ia32 basic arch manual which says the address is zero-extended
>>>> from 32bit after computing it.  So there is no problem?
>>>>
>>>
>>> In x32 mode, we use (%rax,%rbx,4), not (%eax,%ebx,4).  When we generate
>>> (%rax,%rbx,4) in x32 mode, we have to put sign-extended value in RBX.
>>
>> TARGET_MEM_REF does not support this kind of addressing mode.  That's
>> one of the results of choosing ptr_mode != Pmode.  TARGET_MEM_REF
>> only supports (%eax,%ebx,4), or lea (%eax,%ebx,4), %ecx; mov %ecx, %rax
>> and (%rax).
>>
>
> lea is also used for arithmetic. Is there a way to tell an RTL is
> TARGET_MEM_REF?

?

>> TARGET_MEM_REF
>> only supports (%eax,%ebx,4), or lea (%eax,%ebx,4), %ecx; mov %ecx, %rax
>> and (%rax).

as in TARGET_MEM_REF <*ax, *bx, 4> needs to be expanded
as

  compute address in ptr_mode, for example with
    lea (%eax,%ebx,4), %ecx
  zero-extend the address
    mov %ecx, %rax
  do the memory access
    mov (%rax), ...

which is a very inefficient way of using addr32 prefix (basically manually
emulating it).

As Jakub says, don't use ptr_mode != Pmode.  Or disable IVOPTs
(it is useless for such port).  I bet you also will run into POINTER_PLUS_EXPR
issues and the fact it does not preserve signedness of the offset operand.

Richard.



More information about the Gcc-patches mailing list