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

[Leonard Chan via llvm-dev]

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>