[llvm-commits] [RFC] Patch 1/3 for the native code compiler of Erlang

[Yiannis Tsiouris]

Hi,

On 05/02/2012 11:58 PM, Jakob Stoklund Olesen wrote:

> On May 2, 2012, at 1:26 PM, Yiannis Tsiouris <gtsiour at softlab.ntua.gr> wrote:
>
>> The problem is that EAX, ECX and EDX are all registers that are involved
>> in argument passing (ARG0, ARG1, ARG2 actually). Thus, when a tailcall
>> needs more than 2 arguments there remains no register to be used for
>> holding the address of the dynamic tail call (as they are the only ones
>> in GR32_TC register class). We were not sure how we should attack this
>> problem, that's why we followed the approach of HiPE and added two more
>> registers  (not involved anywhere else in the HiPE CC).
>>
>> What do you think we should do for that? Shouldn't the registers
>> involved in this class be somehow co-related with the user-defined
>> calling conventions?
> Yes, and there is already a target hook for exactly that. Look at X86RegisterInfo::getPointerRegClass(). It should return GR32 for ptr_rc_tailcall(=2) when compiling a HiPE function.
>
> It looks like you will need to add an MI pointer argument to the getPointerRegClass target hook. Please do that in a separate patch.
>
> /jakob
The proposed approach (after r156328), i.e. something like:

> ...
>  case 2: // Available for tailcall (not callee-saved GPRs).
>    if (TM.getSubtarget<X86Subtarget>().isTargetWin64())
>      return &X86::GR64_TCW64RegClass;
>    if (TM.getSubtarget<X86Subtarget>().is64Bit())
>      return &X86::GR64_TCRegClass;
>    if (MF.getFunction()->getCallingConv() == CallingConv::HiPE)
>      return &X86::GR32RegClass;
>    return &X86::GR32_TCRegClass;
>  }
>}

in X86RegisterInfo::getPointerRegClass() didn't actually work. Trying to
track down the problem I noticed that the reference to GR32_TC that
really works for us (or that was fixing our problem with the
changing-GR32_TC hack) is the one in X86InstrControl.td line 190:

>  def TCRETURNri : PseudoI<(outs),
>                                  (ins GR32_TC:$dst, i32imm:$offset,
variable_ops), []>;

Changing the register class of the TCRETURNri pseudo-instruction in GR32
makes the difference. Is there a hook for that too? Would it be correct
if I changed the TargetInstrInfo::getRegClass() to trigger
TRI->getPointerRegClass() when compiling a HiPE function? Something like:

>  if (MCID.OpInfo[OpNum].isLookupPtrRegClass()
>        || MF.getFunction()->getCallingConv == CalingConv::HiPE)
>    return TRI->getPointerRegClass(MF, RegClass);

I really want to make it the "right" way, thus any advice is welcome!

Best,
Yiannis

-- 
Yiannis Tsiouris
Ph.D. student,
Software Engineering Laboratory,
National Technical University of Athens
WWW: http://www.softlab.ntua.gr/~gtsiour