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

[James Y Knight via llvm-dev]

IIUC, the actual requirements for the proposed pltentry(@X) constant is:
1. The returned address MUST have a constant offset at link-time from some
other unspecified but defined-in-the-same-binary/DSO symbol Y. Which symbol
it is is presumed not to matter because all locally-defined symbols have
constant offsets from each-other, anyhow.
2. The address is otherwise insignificant. (Therefore, coming up with a
brand new unique address, by creating a local stub function, would be an
acceptable implementation.)

These requirements do seem somewhat generic: even on a system which has a
different way to make a call could still create a local stub function, and
give you the address of that. However, "unnamed address" isn't a good
name, because it doesn't capture the first requirement, only the second.



On Mon, Aug 31, 2020 at 4:46 PM Leonard Chan via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I think I follow. So in this case, it's better to be explicit and say
> "this could lower to a PLT entry (which is only supported on specific
> targets)" rather than making something general that can exist on all
> targets. Makes sense. I wasn't sure if there was perhaps something
> equivalent on other targets that this could lower to, but we can make this
> target/PLT specific.
>
> On Sun, Aug 30, 2020 at 3:55 PM Chris Lattner <clattner at nondot.org> wrote:
>
>>
>>
>> On Aug 29, 2020, at 6:53 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>>
>>
>> Sorry for the delay responding Leonard.  I don’t really understand your
>> rationale here.  A PLT entry is a completely target specific concept
>> because some targets don’t have PLTs.  I don’t think there is any reason
>> that a frontend would abstractly generate this unless they already have a
>> target-specific plan in mind.
>>
>> If you go with your “unnamedfunc” approach, you’ll have to define the
>> semantics of what that means, and it will need to mean something on targets
>> without a PLT.  If it isn’t generally implementable, then it is target
>> specific again.
>>
>> I feel like you are trying (earnestly!) to make the IR better here, but
>> by making this abstract it is actually just making it more opaque for no
>> obvious benefit.
>>
>>
>> +1 to this. LLVM already has a large issue with implicit ABI contracts
>> between Clang (and other frontends) and the various backends. We should not
>> make that worse. The problem here is that there are multiple ways to
>> represent the reference to the function symbol, and in this case, there's
>> an ABI requirement to pick a specific one of them. We should make that
>> clear and explicit. If there's an abstraction here that's useful, it's in
>> the way to pass along that target-specific information -- I think of this
>> like a target-specific attribute.
>>
>> Completely agreed, a lot of my perspective comes from bitter experience
>> having messed up the ABI lowering design :-).  Sorry for that :)
>>
>> -Chris
>>
> _______________________________________________
> 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/20200831/d555a3e6/attachment.html>