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

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200830/9b908dbd/attachment.html>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200831/3f6ce9b2/attachment.html>

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>