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

[Hal Finkel via llvm-dev]

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>