[PATCH] D20348: IR: Introduce local_unnamed_addr attribute.

Tue May 17 18:07:57 PDT 2016

Thanks for the detailed write-up, and sorry to Rafael and Mehdi that it's
on a new thread. =/

On Tue, May 17, 2016 at 5:59 PM Peter Collingbourne via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> pcc created this revision.
> pcc added reviewers: rafael, joker.eph, chandlerc, majnemer.
> pcc added a subscriber: llvm-commits.
> Herald added a reviewer: tstellarAMD.
> Herald added subscribers: jfb, mzolotukhin, joker.eph, arsenm.
>
> If a local_unnamed_addr attribute is attached to a global, the address
> is known to be insignificant within the module. It is distinct from the
> existing unnamed_addr attribute in that it only describes a local property
> of the module rather than a global property of the symbol.
>
> This attribute is intended to be used by the code generator and LTO to
> allow
> the linker to decide whether the global needs to be in the symbol table.
> It is
> possible to exclude a global from the symbol table if three things are
> true:
> - This attribute is present on every instance of the global (which means
> that
>   the normal rule that the global must have a unique address can be broken
> without
>   being observable by the program by performing comparisons against the
> global's
>   address)
> - The global has linkonce_odr linkage (which means that each linkage unit
> must have
>   its own copy of the global if it requires one, and the copy in each
> linkage unit
>   must be the same)
> - It is a constant or a function (which means that the program cannot
> observe that
>   the unique-address rule has been broken by writing to the global)
>
> Although this attribute could in principle be computed from the module
> contents, LTO clients (i.e. linkers) will normally need to be able to
> compute
> this property as part of symbol resolution, and it would be inefficient to
> materialize every module just to compute it.
>

Cool, this last part is really key.

My real problem with adding this as a normal attribute is that I'm not sure
what it really means. Is it just a "cache" of some local analysis? Do we
expect things to invalidate it if they make the address significant within
a module? Is this something that would be "blessed" by some frontends?

I feel like, from your description, this really is just intended to solve
the problem of materializing all of the module. It would seem that for that
purpose something more akin to the "summary" information used by ThinLTO
would be a better tool than an attribute which has to have a semantic
contract for the IR.

What do you think?

>
> See:
>
> http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html
>
> http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html
> for earlier discussion.
>
> Part of the fix for PR27553.
>
> http://reviews.llvm.org/D20348
>
> Files:
>   docs/BitCodeFormat.rst
>   docs/LangRef.rst
>   include/llvm/IR/GlobalValue.h
>   lib/Analysis/InstructionSimplify.cpp
>   lib/AsmParser/LLLexer.cpp
>   lib/AsmParser/LLParser.cpp
>   lib/AsmParser/LLParser.h
>   lib/AsmParser/LLToken.h
>   lib/Bitcode/Reader/BitcodeReader.cpp
>   lib/Bitcode/Writer/BitcodeWriter.cpp
>   lib/CodeGen/Analysis.cpp
>   lib/CodeGen/AsmPrinter/AsmPrinter.cpp
>   lib/CodeGen/TargetLoweringObjectFileImpl.cpp
>   lib/ExecutionEngine/Orc/IndirectionUtils.cpp
>   lib/IR/AsmWriter.cpp
>   lib/IR/Core.cpp
>   lib/IR/Globals.cpp
>   lib/IR/IRBuilder.cpp
>   lib/IR/Verifier.cpp
>   lib/Linker/IRMover.cpp
>   lib/Linker/LinkModules.cpp
>   lib/Target/AMDGPU/AMDGPUPromoteAlloca.cpp
>   lib/Target/TargetLoweringObjectFile.cpp
>   lib/Transforms/IPO/ConstantMerge.cpp
>   lib/Transforms/IPO/GlobalOpt.cpp
>   lib/Transforms/IPO/MergeFunctions.cpp
>   lib/Transforms/Instrumentation/AddressSanitizer.cpp
>   lib/Transforms/Instrumentation/GCOVProfiling.cpp
>   lib/Transforms/Instrumentation/InstrProfiling.cpp
>   lib/Transforms/Scalar/LoopIdiomRecognize.cpp
>   lib/Transforms/Utils/FunctionImportUtils.cpp
>   lib/Transforms/Utils/GlobalStatus.cpp
>   lib/Transforms/Utils/SimplifyCFG.cpp
>   test/Assembler/local-unnamed-addr.ll
>   test/Bitcode/compatibility.ll
>   test/CodeGen/PowerPC/weak_def_can_be_hidden.ll
>   test/CodeGen/X86/weak_def_can_be_hidden.ll
>   test/Feature/OperandBundles/pr26510.ll
>   test/LTO/X86/cfi_endproc.ll
>   test/LTO/X86/linkonce_odr_func.ll
>   test/Other/constant-fold-gep.ll
>   test/Transforms/GlobalOpt/2010-10-19-WeakOdr.ll
>   test/Transforms/GlobalOpt/alias-used-address-space.ll
>   test/Transforms/GlobalOpt/alias-used.ll
>   test/Transforms/GlobalOpt/assume.ll
>   test/Transforms/GlobalOpt/constantfold-initializers.ll
>   test/Transforms/GlobalOpt/ctor-list-opt-inbounds.ll
>   test/Transforms/GlobalOpt/invariant.group.barrier.ll
>   test/Transforms/GlobalOpt/invoke.ll
>   test/Transforms/GlobalOpt/pr21191.ll
>   test/Transforms/GlobalOpt/unnamed-addr.ll
>   test/tools/gold/X86/coff.ll
>   test/tools/gold/X86/emit-llvm.ll
>   tools/gold/gold-plugin.cpp
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160518/2858fe59/attachment.html>