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

[Leonard Chan via llvm-dev]

I see. Perhaps something like "dso_local_stub" or "dso_local_unnamed_stub"
would be better naming? The dso_local bit I think captures the first
requirement and, if kept generic, we could have the default implementation
be this local stub.

On Mon, Aug 31, 2020 at 2:22 PM James Y Knight <jyknight at google.com> wrote:

> 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/20200901/0087ee56/attachment.html>