PATCH [1/n] addr32: Properly use Pmode and word_mode

H.J. Lu hjl.tools@gmail.com
Mon Mar 5 17:12:00 GMT 2012


On Sun, Mar 4, 2012 at 11:47 PM, Uros Bizjak <ubizjak@gmail.com> wrote:
> On Mon, Mar 5, 2012 at 4:53 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>
>> and compiler does generate the same output. i386.c also has
>>
>>        xasm = "jmp\t%A0";
>>    xasm = "call\t%A0";
>>
>> for calls.  There are no separate indirect call patterns.  For x32,
>> only indirect register calls have to be in DImode.  The direct call
>> should be in Pmode (SImode).
>
> Direct call just expects label to some abolute address that is assumed
> to fit in 32 bits (see constant_call_address_operand_p).
>
> call and jmp insn expect word_mode operands, so please change
> ix86_expand_call and call patterns in the same way as jump
> instructions above.
>
>> Since x86-64 hardware always zero-extends upper 32bits of 64bit
>> registers when loading its lower 32bits, it is safe and easier to just
>> to output 64bit registers for %A than zero-extend it by hand for all
>> jump/call patterns.
>
> No, the instruction expects word_mode operands, so we have to extend
> values to expected mode. I don't think that patching at insn output
> time is acceptable.

You are right. I found a testcase to show problem:

struct foo
{
  void (*f) (void);
  int i;
};

void
__attribute__ ((noinline))
bar (struct foo x)
{
  x.f ();
}

"x" is passed in RDI and the uppper 32bits of RDI is "int i".

> BTW: I propose to split the patch into smaller pieces, dealing with
> various independent parts separately. Handling jump/call insn is
> definitely one of them, the other is stringops handling, another
> prologue/epilogue expansion.
>

I will do that.

Thanks.

-- 
H.J.



More information about the Gcc-patches mailing list