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

[Leonard Chan via llvm-dev]

Hi all. Are there any thoughts on the new name idea ("dso_local_stub" or
"dso_local_unnamed_stub")? I'd like to see if I can move forward with my
patch.

On Tue, Sep 1, 2020 at 11:01 AM Leonard Chan <leonardchan at google.com> wrote:

> 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/20200917/7d832a29/attachment.html>