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

Eli Friedman via llvm-dev llvm-dev at lists.llvm.org
Fri Aug 21 18:13:55 PDT 2020


> -----Original Message-----
> From: Fāng-ruì Sòng <maskray at google.com>
> Sent: Friday, August 21, 2020 4:04 PM
> To: Eli Friedman <efriedma at quicinc.com>
> Cc: Leonard Chan <leonardchan at google.com>; llvm-dev at lists.llvm.org
> Subject: [EXT] Re: [llvm-dev] [RFC][LLVM] New Constant type for
> representing function PLT entries
>
> On Fri, Aug 21, 2020 at 3:32 PM Eli Friedman <efriedma at quicinc.com> wrote:
> >
> > > -----Original Message-----
> > > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Fangrui
> > > Song via llvm-dev
> > > Sent: Thursday, August 20, 2020 10:18 PM
> > > To: Leonard Chan <leonardchan at google.com>
> > > Cc: llvm-dev <llvm-dev at lists.llvm.org>
> > > Subject: [EXT] Re: [llvm-dev] [RFC][LLVM] New Constant type for
> > > representing function PLT entries
> > >
> > Maybe it would make sense to introduce a GlobalValue to represent this,
> > along the lines of GlobalIFunc?  I guess the end result isn't a lot different
> > from the original proposal: you still end up with a Constant that represents
> > the PLT entry.  But I think it would fit more smoothly into existing
> > optimizations that understand GlobalValues.  And it would make it clear that
> > importing one from another IR module might be a non-trivial operation.  (I
> > don't think we actually do cross-DSO optimizations at the moment, but it's
> > not outside the realm of possibility.)
> >
> A new subclass of GlobalIndirectSymbol? Looks fine. Do you think the
> name "plt" should be moved from the name of the subclass to an
> argument of the syntax (like alias/ifunc)?

The IR concept could be generalized so it doesn't actually depend on the object format having a PLT.  For example, it could be used to refer to an import thunk on Windows.  So I'm not sure we want to name the IR concept after a "PLT".

LLVM IR currently has the dso_local concept, so maybe we want to leverage that in the name. Maybe something like GlobalDSOLocalFunc?  (Not sure I'm really happy with that exact name, but hopefully the idea makes sense.)

-Eli



More information about the llvm-dev mailing list