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

Eric Christopher via llvm-dev llvm-dev at lists.llvm.org
Thu Aug 20 20:35:15 PDT 2020


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>


More information about the llvm-dev mailing list