On Sun, Mar 4, 2012 at 11:47 PM, Uros Bizjak <ubiz...@gmail.com> wrote:
> On Mon, Mar 5, 2012 at 4:53 AM, H.J. Lu <hjl.to...@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;

__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.



Reply via email to