llvm dev - Aug 2020 - [RFC][LLVM] New Constant type for representing function PLT entries

I do have concerns about the amount of object level modeling that we want
to do in the IR though. While it isn't the highest level IR we've
managed
to mostly avoid these kinds of features/complications in the past. I'm
definitely interested in hearing some alternate implementations here and
there rather than a full set of constants for relocations. Keeping the IR
abstract enough over the object file level other than in generalizable
cases still feels like a win.

-eric

On Thu, Aug 20, 2020 at 8:44 PM Chris Lattner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi Leonard,
>
> I haven’t looked at your patch in detail, but I think that this is a step
> in the right direction.  I would like to see new “Constant*”’s that
> directly map onto the relocations that various object formats use (for
> example, macho has a relocation for “&g1-&g2+cst”).  This would get
us to a
> more principled lowering in many cases as well as make the backend modeling
> more specific.
>
> -Chris
>
> On Aug 20, 2020, at 11:29 AM, Leonard Chan via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hi all,
>
> We would like to propose a new Constant type in LLVM for representing
> entries in the Procedure Linkage Table (PLT).
>
> The PLT is a data structure used for dispatching position-independent
> function calls to appropriate functions where the address of the function
> is not known statically. Right now, if a call is made to a function, it may
> be lowered to a direct call to the function itself or the PLT entry for
> that function. LLVM has checks that dictate if the function call should be
> a direct reference or PLT entry, but we don’t have a way in IR to
> semantically represent that the PLT entry should be used.
>
> The proposed constant would be analogous to BlockAddress, but instead
> represent the PLT entry for functions. The usage could look something like:
>
> pltentry(@function)
>
> and would always have the same type as the function. A pltentry would
> operate exactly like a function, but the main difference is that it’s
> lowered to the PLT entry (function at plt) on targets that support PLT
> relocations. The linker can then decide if it should be relaxed into a
> direct reference or remain a PLT entry.
>
> I have a very rough WIP implementation at https://reviews.llvm.org/D77248.
>
> Thoughts and opinions?
>
> Thanks,
> Leonard
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> _______________________________________________
> 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/20200820/1a559cb0/attachment.html>

On 2020-08-20, Eric Christopher via llvm-dev wrote:
>I do have concerns about the amount of object level modeling that we want
>to do in the IR though. While it isn't the highest level IR we've
managed
>to mostly avoid these kinds of features/complications in the past. I'm
>definitely interested in hearing some alternate implementations here and
>there rather than a full set of constants for relocations. Keeping the IR
>abstract enough over the object file level other than in generalizable
>cases still feels like a win.
>
>-eric
>
>On Thu, Aug 20, 2020 at 8:44 PM Chris Lattner via llvm-dev <
>llvm-dev at lists.llvm.org> wrote:
>
>> Hi Leonard,
>>
>> I haven’t looked at your patch in detail, but I think that this is a
step
>> in the right direction.  I would like to see new “Constant*”’s that
>> directly map onto the relocations that various object formats use (for
>> example, macho has a relocation for “&g1-&g2+cst”).  This would
get us to a
>> more principled lowering in many cases as well as make the backend
modeling
>> more specific.
>>
>> -Chris
>>
>> On Aug 20, 2020, at 11:29 AM, Leonard Chan via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> Hi all,
>>
>> We would like to propose a new Constant type in LLVM for representing
>> entries in the Procedure Linkage Table (PLT).
>>
>> The PLT is a data structure used for dispatching position-independent
>> function calls to appropriate functions where the address of the
function
>> is not known statically. Right now, if a call is made to a function, it
may
>> be lowered to a direct call to the function itself or the PLT entry for
>> that function. LLVM has checks that dictate if the function call should
be
>> a direct reference or PLT entry, but we don’t have a way in IR to
>> semantically represent that the PLT entry should be used.
>>
>> The proposed constant would be analogous to BlockAddress, but instead
>> represent the PLT entry for functions. The usage could look something
like:
>>
>> pltentry(@function)
>>
>> and would always have the same type as the function. A pltentry would
>> operate exactly like a function, but the main difference is that it’s
>> lowered to the PLT entry (function at plt) on targets that support PLT
>> relocations. The linker can then decide if it should be relaxed into a
>> direct reference or remain a PLT entry.
>>
>> I have a very rough WIP implementation at
https://reviews.llvm.org/D77248.
>>
>> Thoughts and opinions?
>>
>> Thanks,
>> Leonard
Note that there is some terminology misnomer or concept confusion here.

A @plt modifer (x86-32, x86-64 and aarch64) in assembly refers to a
function whose address can be insignificant. The assembler produces an
R_386_PLT32/R_X86_64_PLT32/R_AARCH64_PLT32 relocation which will be
resolved by the linker to either:

* the definition (non-preemptible (logical AND (non-ifunc or ld.lld -z
ifunc-noplt is specified)))
* a PLT entry (other cases)

The address can be insignificant: ultimately the program will call the
function. There is no difference if the program calls the function
directly or calls through one PLT entry in any module (executable or a
shared object).

R_386_PC32/R_X86_64_PC32/R_AARCH64_PREL32

The proposd 'pltentry' syntax is an IR level concept to lower the
address of constant to use the @plt modifier.

A Procedure Linkage Table (PLT) entry may or may not be created by the
linker - if it is not necessary, the linker will not create it.  I think
we do need some way to represent this in IR, but I hope we can find a
better name for this concept. Many will think "PLT is a pure linker
synthesized entry - why do we bother calling some compiler-generated
stuff PLT". The @plt assembly syntax is a bit unfortunate as well - I
suggested it anyway in https://reviews.llvm.org/D81184 because its x86
counterpart had used this concept for many years.
> The compiler should not assume that a Function will be lowered to the
> PLT entry for it, so we can use this instead to semantically
> represent in LLVM that a PLT should be used.
The "PLT entry" part of the sentence is not entirely correct.

+1 to Eric's point. We could get into a state where we must get the
relocation right in the IR to get a good (or worse, any) lowering.

I'd rather have a canonical representation, relocation friendly, that we
try to keep and back ends know how to lower well.

--renato

On Fri, 21 Aug 2020, 04:35 Eric Christopher via llvm-dev, <
llvm-dev at lists.llvm.org> wrote:
> I do have concerns about the amount of object level modeling that we want
> to do in the IR though. While it isn't the highest level IR we've
managed
> to mostly avoid these kinds of features/complications in the past. I'm
> definitely interested in hearing some alternate implementations here and
> there rather than a full set of constants for relocations. Keeping the IR
> abstract enough over the object file level other than in generalizable
> cases still feels like a win.
>
> -eric
>
> On Thu, Aug 20, 2020 at 8:44 PM Chris Lattner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi Leonard,
>>
>> I haven’t looked at your patch in detail, but I think that this is a
step
>> in the right direction.  I would like to see new “Constant*”’s that
>> directly map onto the relocations that various object formats use (for
>> example, macho has a relocation for “&g1-&g2+cst”).  This would
get us to a
>> more principled lowering in many cases as well as make the backend
modeling
>> more specific.
>>
>> -Chris
>>
>> On Aug 20, 2020, at 11:29 AM, Leonard Chan via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> Hi all,
>>
>> We would like to propose a new Constant type in LLVM for representing
>> entries in the Procedure Linkage Table (PLT).
>>
>> The PLT is a data structure used for dispatching position-independent
>> function calls to appropriate functions where the address of the
function
>> is not known statically. Right now, if a call is made to a function, it
may
>> be lowered to a direct call to the function itself or the PLT entry for
>> that function. LLVM has checks that dictate if the function call should
be
>> a direct reference or PLT entry, but we don’t have a way in IR to
>> semantically represent that the PLT entry should be used.
>>
>> The proposed constant would be analogous to BlockAddress, but instead
>> represent the PLT entry for functions. The usage could look something
like:
>>
>> pltentry(@function)
>>
>> and would always have the same type as the function. A pltentry would
>> operate exactly like a function, but the main difference is that it’s
>> lowered to the PLT entry (function at plt) on targets that support PLT
>> relocations. The linker can then decide if it should be relaxed into a
>> direct reference or remain a PLT entry.
>>
>> I have a very rough WIP implementation at
https://reviews.llvm.org/D77248
>> .
>>
>> Thoughts and opinions?
>>
>> Thanks,
>> Leonard
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> 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/20200821/9c076d36/attachment.html>

On 8/21/20 1:34 AM, Renato Golin via llvm-dev wrote:
> +1 to Eric's point. We could get into a state where we must get the 
> relocation right in the IR to get a good (or worse, any) lowering.
>
> I'd rather have a canonical representation, relocation friendly, that 
> we try to keep and back ends know how to lower well.
>
> --renato

FWIW, I think that we all agree to that. I don't see that what's being 
proposed changes this general philosophy. The general problem is: what 
happens when that lowering has multiple good options, and the ABI 
requires particular choices under certain circumstances?

Thanks again,

Hal

>
> On Fri, 21 Aug 2020, 04:35 Eric Christopher via llvm-dev, 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>
>     I do have concerns about the amount of object level modeling that
>     we want to do in the IR though. While it isn't the highest level
>     IR we've managed to mostly avoid these kinds of
>     features/complications in the past. I'm definitely interested in
>     hearing some alternate implementations here and there rather than
>     a full set of constants for relocations. Keeping the IR abstract
>     enough over the object file level other than in generalizable
>     cases still feels like a win.
>
>     -eric
>
>     On Thu, Aug 20, 2020 at 8:44 PM Chris Lattner via llvm-dev
>     <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>
>         Hi Leonard,
>
>         I haven’t looked at your patch in detail, but I think that
>         this is a step in the right direction.  I would like to see
>         new “Constant*”’s that directly map onto the relocations that
>         various object formats use (for example, macho has a
>         relocation for “&g1-&g2+cst”).  This would get us to a more
>         principled lowering in many cases as well as make the backend
>         modeling more specific.
>
>         -Chris
>
>>         On Aug 20, 2020, at 11:29 AM, Leonard Chan via llvm-dev
>>         <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>>
>>         Hi all,
>>
>>         We would like to propose a new Constant type in LLVM for
>>         representing entries in the Procedure Linkage Table (PLT).
>>
>>         The PLT is a data structure used for dispatching
>>         position-independent function calls to appropriate functions
>>         where the address of the function is not known statically.
>>         Right now, if a call is made to a function, it may be lowered
>>         to a direct call to the function itself or the PLT entry for
>>         that function. LLVM has checks that dictate if the function
>>         call should be a direct reference or PLT entry, but we don’t
>>         have a way in IR to semantically represent that the PLT entry
>>         should be used.
>>
>>         The proposed constant would be analogous to BlockAddress, but
>>         instead represent the PLT entry for functions. The usage
>>         could look something like:
>>
>>         pltentry(@function)
>>
>>         and would always have the same type as the function. A
>>         pltentrywould operate exactly like a function, but the main
>>         difference is that it’s lowered to the PLT entry
>>         (function at plt) on targets that support PLT relocations. The
>>         linker can then decide if it should be relaxed into a direct
>>         reference or remain a PLT entry.
>>
>>         I have a very rough WIP implementation at
>>         https://reviews.llvm.org/D77248
>>         <https://reviews.llvm.org/D77248>.
>>
>>         Thoughts and opinions?
>>
>>         Thanks,
>>         Leonard
>>
>>         _______________________________________________
>>         LLVM Developers mailing list
>>         llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>         https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>        
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
>         _______________________________________________
>         LLVM Developers mailing list
>         llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>         https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>         <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200821/6d5d3154/attachment.html>

> -----Original Message-----
> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of
Fangrui
> Song via llvm-dev
> Sent: Thursday, August 20, 2020 10:18 PM
> To: Leonard Chan <leonardchan at google.com>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>
> Subject: [EXT] Re: [llvm-dev] [RFC][LLVM] New Constant type for
> representing function PLT entries
>
> A @plt modifer (x86-32, x86-64 and aarch64) in assembly refers to a
> function whose address can be insignificant. The assembler produces an
> R_386_PLT32/R_X86_64_PLT32/R_AARCH64_PLT32 relocation which will be
> resolved by the linker to either:
>
> * the definition (non-preemptible (logical AND (non-ifunc or ld.lld -z
ifunc-
> noplt is specified)))
> * a PLT entry (other cases)
>
> The address can be insignificant: ultimately the program will call the
> function. There is no difference if the program calls the function
> directly or calls through one PLT entry in any module (executable or a
> shared object).
>
> R_386_PC32/R_X86_64_PC32/R_AARCH64_PREL32
Ignoring the ELF-specific bits, in essence, it's some dso-local function
that's functionally equivalent to the actual resolved function at runtime. 
The address may or may not be equal to that of the resolved function.

Maybe it would make sense to introduce a GlobalValue to represent this, along
the lines of GlobalIFunc?  I guess the end result isn't a lot different from
the original proposal: you still end up with a Constant that represents the PLT
entry.  But I think it would fit more smoothly into existing optimizations that
understand GlobalValues.  And it would make it clear that importing one from
another IR module might be a non-trivial operation.  (I don't think we
actually do cross-DSO optimizations at the moment, but it's not outside the
realm of possibility.)

-Eli
> The proposd 'pltentry' syntax is an IR level concept to lower the
> address of constant to use the @plt modifier.
>
> A Procedure Linkage Table (PLT) entry may or may not be created by the
> linker - if it is not necessary, the linker will not create it.  I think
> we do need some way to represent this in IR, but I hope we can find a
> better name for this concept. Many will think "PLT is a pure linker
> synthesized entry - why do we bother calling some compiler-generated
> stuff PLT". The @plt assembly syntax is a bit unfortunate as well - I
> suggested it anyway in https://reviews.llvm.org/D81184 because its x86
> counterpart had used this concept for many years.

Sure, I also don’t like unnecessary complexity.  Let me try to motivate this
along two different points: expressivity, and simplicity.

On Expressivity, LLVM IR *in general* provides an abstract representation that
allows frontends to generate target independent(ish!) IR, instead of having to
understand all of the target details, e.g. you shouldn’t have to know the target
to get an integer add.  However, the model is really that we provide *both* a
target independent model and a target-specific model.  You can see this in
calling conventions, you can see this in target-specific intrinsics, you can see
this in inline assembly.  In my opinion these are all good examples of LLVM
providing target-independent abstractions, while still allowing frontends to get
to the full capability of the hardware/architecture/target.  Making addressing
modes for relocations consistent with that seems like a good thing.


On simplicity, I’ve mentioned before that the right thing is to redesign
ConstantExpr entirely, eliminating most of the operations.  “Trapping” constants
(like divide) is a huge bug in the representation, and is only there for
historical reasons.  When you get beyond the fundamental integer and FP
constants, the only reason we have aggregates (ConstantArray) and ConstantExpr
is to enable global variable initializers that contain relocations.  Things like
constants (and particularly constant exprs) in PHI nodes are persistent problems
at the LLVM IR level that would be better defined away.  As such, a reasonable
design for constants would be “fundamental constants within function bodies;
possibly using an MLIR like representation to define away even these” and
“global variable initializers”.  Note that there is no specific reason that
“global variable initializers” be Value*’s.

In any case, I think the first thing is motivation alone.  Doing so would be a
stepping stone to get rid of all the crazy backend logic that tries to match
"gv-gv+cst” etc, instead allowing this to be done on the IR level.

-Chris
> On Aug 20, 2020, at 8:35 PM, Eric Christopher <echristo at gmail.com>
wrote:
> 
> I do have concerns about the amount of object level modeling that we want
to do in the IR though. While it isn't the highest level IR we've
managed to mostly avoid these kinds of features/complications in the past.
I'm definitely interested in hearing some alternate implementations here and
there rather than a full set of constants for relocations. Keeping the IR
abstract enough over the object file level other than in generalizable cases
still feels like a win.
> 
> -eric
> 
> On Thu, Aug 20, 2020 at 8:44 PM Chris Lattner via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Hi Leonard,
> 
> I haven’t looked at your patch in detail, but I think that this is a step
in the right direction.  I would like to see new “Constant*”’s that directly map
onto the relocations that various object formats use (for example, macho has a
relocation for “&g1-&g2+cst”).  This would get us to a more principled
lowering in many cases as well as make the backend modeling more specific.
> 
> -Chris
> 
>> On Aug 20, 2020, at 11:29 AM, Leonard Chan via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 
>> Hi all,
>> 
>> We would like to propose a new Constant type in LLVM for representing
entries in the Procedure Linkage Table (PLT).
>> 
>> The PLT is a data structure used for dispatching position-independent
function calls to appropriate functions where the address of the function is not
known statically. Right now, if a call is made to a function, it may be lowered
to a direct call to the function itself or the PLT entry for that function. LLVM
has checks that dictate if the function call should be a direct reference or PLT
entry, but we don’t have a way in IR to semantically represent that the PLT
entry should be used.
>> 
>> The proposed constant would be analogous to BlockAddress, but instead
represent the PLT entry for functions. The usage could look something like:
>> 
>> pltentry(@function)
>> 
>> and would always have the same type as the function. A pltentry would
operate exactly like a function, but the main difference is that it’s lowered to
the PLT entry (function at plt) on targets that support PLT relocations. The
linker can then decide if it should be relaxed into a direct reference or remain
a PLT entry.
>> 
>> I have a very rough WIP implementation at
https://reviews.llvm.org/D77248 <https://reviews.llvm.org/D77248>.
>> 
>> Thoughts and opinions?
>> 
>> Thanks,
>> Leonard
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<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/20200821/72fe155a/attachment.html>