I’ve recently encountered a problem with X86 segment registers.
I created a new calling convention and for some purposes I have to use a segment register for one of the argument passed by the caller. I found out that in X86RegisterInfo.td, SEGMENT_REG was defined there, and I directly grabbed the one I need into my calling convention in X86CallingConv.td. However, I got an error while I was trying to codegen a function with my specific calling convention. The error is "Cannot emit physreg copy instruction” which is in llvm::X86InstrInfo::copyPhysReg when it tries to copy the segment register. I think the problem occurs at the beginning of the function when it tries to get the argument from the segment register. Does anyone have any idea on how to fix it or the correct way to use the segment register?
Thanks in advance!
Does anyone have any idea on how to fix it or the correct way to use the
At the moment LLVM only uses segment registers passively, where the
actual value in the register isn't changed by LLVM (for example
thread-local storage access is via %fs on Linux, but that value is set
by the OS when the thread is created and we don't need to worry about
Because of that, we don't have infrastructure in place for actually
shuffling values around them and you should probably expect to have to
add bits yourself as you go along.
You've discovered copyPhysReg (you'll have to implement a copy
yourself, probably with push/pop like EFLAGS since there's no direct
seg/seg move instruction). You'll probably eventually need to be able
to spill & restore them too, if lots of moves are going on (the
storeRegToStackSlot and loadRegFromStackSlot functions).
Depending on what you're trying to do that may be everything, or you
may meet even more worlds of pain later on.
Thanks for the suggestions.
Currently all I need is actually to read the value from one of the segment registers (specifically the GS register). And based on the LLVM X86 Language Extensions, annotating a pointer with address space #256 can codegen relative to the GS register. So I guess this approach seems to be easier and cleaner than hacking the LLVM internal?