<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 21, 2020 at 4:04 PM Fāng-ruì Sòng via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Aug 21, 2020 at 3:32 PM Eli Friedman <<a href="mailto:efriedma@quicinc.com" target="_blank">efriedma@quicinc.com</a>> wrote:<br>
><br>
> > -----Original Message-----<br>
> > From: llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> On Behalf Of Fangrui<br>
> > Song via llvm-dev<br>
> > Sent: Thursday, August 20, 2020 10:18 PM<br>
> > To: Leonard Chan <<a href="mailto:leonardchan@google.com" target="_blank">leonardchan@google.com</a>><br>
> > Cc: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
> > Subject: [EXT] Re: [llvm-dev] [RFC][LLVM] New Constant type for<br>
> > representing function PLT entries<br>
> ><br>
> > A @plt modifer (x86-32, x86-64 and aarch64) in assembly refers to a<br>
> > function whose address can be insignificant. The assembler produces an<br>
> > R_386_PLT32/R_X86_64_PLT32/R_AARCH64_PLT32 relocation which will be<br>
> > resolved by the linker to either:<br>
> ><br>
> > * the definition (non-preemptible (logical AND (non-ifunc or ld.lld -z ifunc-<br>
> > noplt is specified)))<br>
> > * a PLT entry (other cases)<br>
> ><br>
> > The address can be insignificant: ultimately the program will call the<br>
> > function. There is no difference if the program calls the function<br>
> > directly or calls through one PLT entry in any module (executable or a<br>
> > shared object).<br>
> ><br>
> > R_386_PC32/R_X86_64_PC32/R_AARCH64_PREL32<br>
><br>
> Ignoring the ELF-specific bits, in essence, it's some dso-local function that's functionally equivalent to the actual resolved function at runtime.  The address may or may not be equal to that of the resolved function.<br>
<br>
Agree.<br>
<br>
> 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.)<br>
><br>
> -Eli<br>
<br>
A new subclass of GlobalIndirectSymbol? Looks fine. Do you think the<br>
name "plt" should be moved from the name of the subclass to an<br>
argument of the syntax (like alias/ifunc)?<br></blockquote><div><br></div><div>I don't think this is a good idea. GlobalValues are meant to represent "symbols", and a PLT entry is not a symbol. Furthermore, this would be a special type of GlobalIndirectSymbol that would not require the referent to be defined (as GlobalAlias and GlobalIFunc do). So I don't see this fitting smoothly into existing code, in fact I suspect that more code would need to be adjusted to handle PLT entries as a special case than if we just made it a Constant.</div><div><br></div><div>Fundamentally this is more similar to ConstantExpr than anything under GlobalValue, but since the operand is required to be a GlobalValue and there would be no corresponding Instruction, the right place to put it is under Constant IMHO.</div><div><br></div><div>Peter</div></div></div>