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

[John McCall via Phabricator via llvm-commits]

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


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77248