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

[Jakob Stoklund Olesen]

On May 8, 2012, at 12:42 PM, Yiannis Tsiouris <gtsiour at softlab.ntua.gr> wrote:

> 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!

You need to use ptr_rc_tailcall instead of GR32_TC in those instruction definitions. That is how getPointerRegClass() gets called.

/jakob