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

Leonard Chan via llvm-dev llvm-dev at lists.llvm.org
Mon Aug 31 13:45:44 PDT 2020

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>

More information about the llvm-dev mailing list