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

[Hal Finkel via llvm-dev]

On 8/29/20 8:27 PM, Chris Lattner via llvm-dev wrote:
> On Aug 24, 2020, at 6:47 PM, Leonard Chan via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> Thanks for the responses! I’m going to see if I can summarize the 
>> concerns and ideas people have (for my own clarity) and see where we 
>> can go on from there. Folks seem to be on board with the idea of 
>> introducing some new IR entity that (after linking) *could* be a 
>> reference into the PLT, but some kinks need to be worked out first:
>>
>> *Naming* (Thanks for clarifications maskray at . I mixed up some 
>> terminology and concepts.): Because the PLT is primarily the concern 
>> of the linker, the naming probably shouldn’t be directly tied to 
>> “PLT”. The initial proposal was for something that matched the @plt 
>> modifier on x86, so that’s what inspired the naming. The intended 
>> behavior of this IR level change is that at least on x86 or aarch64, 
>> the resolved constant could be lowered to something that has the 
>> `@plt` syntax, but I suppose other targets could have their own 
>> meaning for “the address of this function is insignificant.”
>>
>> *Abstraction*: The IR representation of this probably shouldn’t be 
>> too strictly mapped to object file representations. It’s useful to 
>> have an IR pattern that can be mapped to relocations on different 
>> binary formats, but 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_addr` where the address of a global variable 
>> is insignificant, but this would instead be tied to instances where 
>> the function is used rather than be attached to the function 
>> declaration/definition. `unnamedfunc(@func)` could be lowered to a 
>> direct reference (func), the @plt modifier on x86/aarch64 (func at plt), 
>> a thunk, or anything that’s equivalent to the resolved function at 
>> runtime.
>
> 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.

  -Hal


>
>> Implementation-wise, I imagine we don’t want this as a subclass of 
>> GlobalValue. As Peter suggested, this may not eventually lower to a 
>> symbol. If it were a GlobalValue, that would also imply linkage types 
>> and visibility would also apply to it which might not make sense. A 
>> GlobalValue also seems to imply a module-level entity when this would 
>> primarily be used on individual locations where a function would 
>> normally be used.
>
> I agree, this should be a subclass of ConstantExpr.
>
> -Chris
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200829/eccd5f72/attachment.html>