[llvm-dev] [RFC] Introduce new call-site attribute

[Philip Reames via llvm-dev]

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:

call void @foo() target-address-relative-bound(-2147483648, 2147483647)

OR

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.  :)

On 9/1/21 6:31 AM, Evgueni Brevnov via llvm-dev wrote:
> Hi Everyone,
>
> 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.
>
> Thanks
> Evgeniy
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210901/2dcef83a/attachment.html>