[llvm-dev] Difference when compiling human readable IR vs bitcode with clang frontend

Dennis Frett via llvm-dev llvm-dev at lists.llvm.org
Fri Jan 18 01:15:13 PST 2019

We've noticed a difference in the embedded bitcode when compiling human readable IR to an object directly vs first compiling IR to BC and then an object through clang -cc1.
If the original IR file contained an "llvm.compiler.used" gv, it will be preserved when compiling IR -> BC -> Obj.
When compiling IR -> Obj directly, it will be removed.

This difference does not exist for the "llvm.used" gv however, it is always preserved.
This questions seems related to the following lit test in LLVM: https://github.com/llvm-mirror/llvm/blob/master/test/Transforms/GlobalOpt/compiler-used.ll.

Is this somehow expected behaviour?

Source taken from the lit test.

define void @foo() {
  ret void

@llvm.used = appending global [1 x i8*] [i8* bitcast (void ()* @foo to i8*)], section "llvm.metadata"
@llvm.compiler.used = appending global [1 x i8*] [i8* bitcast (void ()* @foo to i8*)], section "llvm.metadata"

# Compile IR -> Obj directly.
clang -cc1 -triple x86_64-apple-macosx10.13.0 -emit-obj -fembed-bitcode=all -x ir test.ll -o test_ll.o

# Compile IR -> BC -> Obj.
clang -cc1 -triple x86_64-apple-macosx10.13.0 -emit-llvm-bc -fblocks -fencode-extended-block-signature -x ir test.ll  -o test.bc
clang -cc1 -triple x86_64-apple-macosx10.13.0 -emit-obj -fembed-bitcode=all -x ir test.bc -o test_bc.o 

# Extract and disassemble embedded bitcode from both scenarios.
segedit test_bc.o -extract __LLVM __bitcode bc_bc.bc
segedit test_ll.o -extract __LLVM __bitcode ll_bc.bc
llvm-dis bc_bc.bc
llvm-dis ll_bc.bc

# Diff both IR files to show that only bc_bc.ll contains "llvm.compiler.used"
diff bc_bc.ll ll_bc.ll

- Dennis Frett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1389 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190118/09565627/attachment.bin>

More information about the llvm-dev mailing list