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

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>

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>

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>