search for: pltentry

...the function call should be a direct reference or PLT entry, but we don’t have a way in IR to semantically represent that the PLT entry should be used. The proposed constant would be analogous to BlockAddress, but instead represent the PLT entry for functions. The usage could look something like: pltentry(@function) and would always have the same type as the function. A pltentry would operate exactly like a function, but the main difference is that it’s lowered to the PLT entry (function at plt) on targets that support PLT relocations. The linker can then decide if it should be relaxed into a direc...

...a direct reference or PLT entry, but we don’t have a way in IR to > semantically represent that the PLT entry should be used. > > The proposed constant would be analogous to BlockAddress, but instead > represent the PLT entry for functions. The usage could look something like: > > pltentry(@function) > > and would always have the same type as the function. A pltentry would > operate exactly like a function, but the main difference is that it’s > lowered to the PLT entry (function at plt) on targets that support PLT > relocations. The linker can then decide if it should...

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 i...

...al 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...

> -----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

...t we don’t want to introduce a state where we have new Constants for individual relocations. The IR-entity should remain abstract enough that it’s not tied to a specific relocation, but it can still be lowered appropriately by different backends. > > As an update to the proposal, instead of `pltentry(@func)`, we can call it something like `unnamedfunc(@func)` and everywhere it’s used, it means: “The value used here is functionally equivalent to the original function, but may not be a reference to the original function. The address of this value is insignificant.” This is leveraged from `unnamed...

...imizations 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.) -Eli > The proposd 'pltentry' syntax is an IR level concept to lower the > address of constant to use the @plt modifier. > > A Procedure Linkage Table (PLT) entry may or may not be created by the > linker - if it is not necessary, the linker will not create it. I think > we do need some way to represent thi...

> 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

...cally represent that the PLT entry >> should be used. >> >> The proposed constant would be analogous to BlockAddress, but >> instead represent the PLT entry for functions. The usage >> could look something like: >> >> pltentry(@function) >> >> and would always have the same type as the function. A >> pltentrywould operate exactly like a function, but the main >> difference is that it’s lowered to the PLT entry >> (function at plt) on targets that support PLT r...