[PATCH] D20348: IR: Introduce local_unnamed_addr attribute.

Rafael EspĂ­ndola via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 7 08:01:31 PDT 2016


I had been convinced that the proper fix was to have an analysis and a
symbol table to put the result in. I then talked with Mehdi on the
social and he had a pretty strong argument why this should actually be
an attribute.

The fundamental issue is that given a bitcode foo.bc, running

$ llvm-dis < foo.bc | llvm-as -o bar.bc

should produce a bar.bc that is equivalent to foo.bc.

The analysis plus symbol table solution has two problems maintaining
this property:

* llvm-as would have to run an analysis, which is at least an odd dependency.
* It would still not produce the same results in the case of a
transformation that introduces a semantic preserving address use. If
the analysis is run early, the original producer of foo.bc (clang for
example) will set the bit in the symbol table saying the address is
not significant, even if a later pass created a use. When the analysis
is run again, llvm-as would get a difference conclusion.

Cheers,
Rafael


More information about the llvm-commits mailing list