Use SEGMENT_REG in X86 calling convention

Hi Fellows,

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, SEGMENT_REG was defined there, and I directly grabbed the one I need into my calling convention in 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!


Hi Chen,

Does anyone have any idea on how to fix it or the correct way to use the
segment register?

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.

Good luck!


Hi Tim,

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?