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

[Chris Lattner via llvm-dev]

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>