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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200820/3175ca84/attachment.html>

Hi, Leonard,

What are the motivating use cases?

  -Hal

On 8/20/20 1:29 PM, Leonard Chan via llvm-dev 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
> 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/20200820/2eea1c47/attachment.html>

>
> Hi, Leonard,
>
> What are the motivating use cases?
>
>  -Hal
>
The immediate use case for us specifically would be a way to explicitly
request static PLT relocations. We rolled out a new relocation for AArch64 (
R_AARCH64_PLT32 <https://reviews.llvm.org/D81184>) which takes the offset
between the PLT entry for a function and some other symbol. In IR, we can
then explicitly request this relocation with `pltentry(@function) -
@global` and distinguish it from `@function - @global` which may or may not
lower to R_AARCH64_PREL32 if both symbols are dso_local. This is especially
useful for the relative vtables ABI <https://reviews.llvm.org/D72959>
where
we can benefit in size by not having to emit dso_local stubs for some
functions.

In the general case, this just adds a way for semantically representing PLT
entries for functions and would ideally add more "correctness". From
an IR
perspective, users won't need to second-guess "what will this function
be
lowered to".
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200820/f18e5352/attachment.html>

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
<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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200820/992b8025/attachment.html>

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>