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

[Renato Golin via llvm-dev]

+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>