Introduction:
On Intel x86_64 architecture you can make a call using either relative 32 bits offset or absolute address. Currently LLVM uses a notion of “code model” that defines which version will be generated. In other words, for small and medium code models 32 bits relative calls are generated, for large code model calls via an absolute address are generated. The thing is that a single lowering scheme is used for the entire compilation unit and there is no way to specialize for a particular call. In managed environments (JIT compilers) we have control where specific functions are loaded in memory and can guarantee that particular call site is within 32-bits offset. We would like to use relative calls for such functions while the global code model is set to ‘large’.
Proposal:
Introduce ‘fits-32bits’ call site attribute. For calls marked with the attribute compiler may assume the target address is within 32-bits offset from the end of the generated call. Program semantics is not changed if it is ignored by the compiler.The attribute overrides the current code model for the specific call site.
The basic problem you’re solving makes sense to me, and I agree we need a good solution. I’m not quite sure that your propose is the right starting point though.
The notion of having different ways to encode targets with different offsets shows up in a bunch of different ways, not just calls, and in particular, not just the pcRel32 flavor you mention here. A few other examples:
For an address which whose relative offset is unknown, but whose absolute address is known, you can use a 32bit move to materialize the address in a register.
For relative calls, x86 supports a 16 bit relative version as well. Though, I’m not sure this is profitable on modern hardware.
With tail calls, you get all the jump variants (8b relative, 16b relative, 32b relative, 32b register, 64b register).
For data accesses, we have many of the same options. I think it’s reasonable to (mostly) start with calls, and ignore the data access side of things.
All of these tightly interlock with the relocations available from the dynamic loader.
I’d previously played with specifying bounds on the absolute addresses of functions. (We have some bit of support for that, though I can’t find it in LangRef currently.) This quickly tripped into implementation complexity problems, but I didn’t see any fundamental reason why e.g. having both callee and caller functions specified to be within a 1.x GB region wouldn’t allow us to use 32 bit relative calls.
I think we need to phrase this as a set of restrictions on both the absolute and relative offset of a callee, and then leave it up to backend to select the optimal lowering. The codemodel in this world becomes simply the default set of restrictions for an otherwise unspecified target address.
All of the above is a really involved way of saving that I think you need to change your spelling on the attribute a bit. I think we need to be able to support fairly arbitrary restrictions on the relative range, and then leave it up to the code generator which option it actually picks. As a strawman, how about the following syntax:
declare void @foo() address-absolute-bound(X, X + 100MB)
Philip
p.s. I’m not a linker or loader person, I know just enough about them to be very dangerous. If anyone who is actually familiar with relocation types wants to tell me something is horrible wrong with my proposed model, please feel free.
The basic problem you're solving makes sense to me, and I agree we need a good solution. I'm not quite sure that your propose is the right starting point though.
The notion of having different ways to encode targets with different offsets shows up in a bunch of different ways, not just calls, and in particular, not just the pcRel32 flavor you mention here. A few other examples:
* For an address which whose relative offset is unknown, but whose
absolute address is known, you can use a 32bit move to materialize
the address in a register.
* For relative calls, x86 supports a 16 bit relative version as
well. Though, I'm not sure this is profitable on modern hardware.
* With tail calls, you get all the jump variants (8b relative, 16b
relative, 32b relative, 32b register, 64b register).
* For data accesses, we have many of the same options. I think it's
reasonable to (mostly) start with calls, and ignore the data
access side of things.
All of these tightly interlock with the relocations available from the dynamic loader.
I'd previously played with specifying bounds on the absolute addresses of functions. (We have some bit of support for that, though I can't find it in LangRef currently.) This quickly tripped into implementation complexity problems, but I didn't see any fundamental reason why e.g. having both callee and caller functions specified to be within a 1.x GB region wouldn't allow us to use 32 bit relative calls.
I agree, this makes sense to me. My bikeshedding suggestion is to store the offsets in log2 form. Something like “target-pc-rel”(32) , “target-pc-rel”(12), “target-pc-abs”(32). This should generalize from X86 to ARM/AArch64 and other ISAs with shorter displacements. Later you could imagine throwing in other relocation variants like “tocrel”, “gotrel”, or anything you need for your particular architecture.
Thank you guys for the input.
Being able to specify arbitrary range (relative or absolute) makes perfect sense to me. As for the format I would propose to simply use the same as absolute_symbol.
