[PATCH] D77248: [llvm][IR] Add dso_local_equivalent Constant

[Leonard Chan via Phabricator via llvm-commits]

leonardchan added inline comments.


================
Comment at: llvm/docs/LangRef.rst:3777
+insignificant. The name is leveraged from ``dso_local`` where use of a function or
+variable is resolved to a symbol in the same linkage unit.
 
----------------
rjmccall wrote:
> There has to be a type for the global in the syntax, right?  Or is that an assumed prefix on this, and then we don't need it separately on the global because it's the same type?
> 
> Also, do we actually need the parens?  I think the other places we use parens here, it actually does meaningful grouping.
> 
> On wording, allow me to suggest:
> 
>   A '``dso_local_equivalent``' constant represents a global value which is functionally equivalent to a given global value, but is always defined in the current linkage unit.  The resulting pointer has the same type as the underlying global.  The resulting pointer is permitted, but not required, to be different from a pointer to the global, and it may have different values in different translation units.
> 
>   The target global may not have ``extern_weak`` linkage.
> 
>   ``dso_local_equivalent`` can be implemented in several ways:
> 
>   - If the global has private or internal linkage, has hidden visibility, or is ``dso_local``, ``dso_local_equivalent`` can be implemented as simply a pointer to the global.
> 
>   - If the global is a function, ``dso_local_equivalent`` can be implemented with a stub that tail-calls the function.  Many targets support relocations that resolve at link time to either a function or a stub for it, depending on if the function is defined within the linkage unit; LLVM will use this when available.  (This is commonly called a "PLT stub".)  On other targets, the stub may have to be emitted explicitly.
> 
>   - If the global is a variable, this can be implemented by copying the contents of the variable into the current linkage unit (as if by `memcpy`).  This is not supported on all targets, and target-specific restrictions may apply.  For example, on ELF this can be implemented as a copy relocation, which requires that the global has the same size at load time as it did at at link time.
> 
> I don't think you need to keep anything from the last paragraph.
> There has to be a type for the global in the syntax, right? Or is that an assumed prefix on this, and then we don't need it separately on the global because it's the same type?

The latter. I was aiming for a syntax similar to `blockaddress`, but we would know the global type since we still need to write it before `dso_local_equivalent`.

> Also, do we actually need the parens? I think the other places we use parens here, it actually does meaningful grouping.

You're right. They can be removed.

Thanks for the suggestion also! The only thing I'd probably clarify on is if this constant accepts "global values" vs "global objects" since global value implies that this could also accept global aliases or global ifuncs. I suppose there's nothing wrong with this: ifuncs can have the same handling as functions, and depending on the aliasee, an alias can have the same handling as a function or variable. It could be that this is already implied, but I'll update to explicitly mention them also.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77248/new/

https://reviews.llvm.org/D77248