Can clang generate the same bitcode with the toolchains that have same version of libraries but different targets

Hi,

I’m using clang to build my project as follows:

$ clang++ -ccc-host-triple arm-none-linux-gnueabi --sysroot=/usr/local/arm-none-linux-gnueabi/arm-none-linux-gnueabi/libc/ -o foo.o -emit-llvm -c foo.cpp

$ clang++ -ccc-host-triple arm-none-linux-gnueabi --sysroot=/usr/local/arm-none-linux-gnueabi/arm-none-linux-gnueabi/libc/ -o main.o -emit-llvm -c main.cpp

$ llvm-link foo.o main.o -o main.bc

$ llc main.bc -o main.ARM.s

$ arm-none-linux-gnueabi-g++ main.ARM.s -o main.ARM

  1. Can clang generate the same bitcode (main.bc in the above example) with the toolchains that have same version of libraries but different targets?

  2. Is there any possibility that the generated bitcode with the ARM toolchain (main.bc in the above example) can be compiled to another platform, like PowerPC or mips?

Currently, I tried the toolchains of ARM and PowerPC that have the different versions of libraries, obviously the generated bitcode are different.
So I wonder whether the version of library is the only reason why the generated bitcode are different.

Thanks,
Kenia Kuo

Kenia Kuo <kenkillerkuo@gmail.com> writes:

[snip]

Currently, I tried the toolchains of ARM and PowerPC that have the
different versions of libraries, obviously the generated bitcode are
different.
So I wonder whether the version of library is the only reason why the
generated bitcode are different.

http://llvm.org/docs/FAQ.html#can-i-compile-c-or-c-code-to-platform-independent-llvm-bitcode

Hi Óscar,

Thank you for your reply.

It looks like the limitations are the platform’s API and ABI (included the size of variable).
So, if there are two platforms that have the same API, ABI but different ISAs, the bitcode can be shared. Can I say that?

Thanks,
Kenia Kuo

2012/9/25 Óscar Fuentes <ofv@wanadoo.es>

    It looks like the limitations are the platform's API and ABI (included the
    size of variable).

  "No. C and C++ are inherently platform-dependent languages."

  The root cause is the programming language, so is LLVM IR.

Regards,
chenwj

Hi Kenia,

What you might be trying to end up with (rather than the question you’re directly asking J ) is a platform independent compiled representation.

(Of course you might be aiming to do something else, like a cross-platform compile farm, in which case I have no input…)

If this is the goal, the google native client team are working on PNaCl, which is (in addition to “safety properties”) designed to be

platform independent

http://www.chromium.org/nativeclient/pnacl/building-and-testing-portable-native-client

I’ve not kept up with this project, but I believe that this is only achieved by considering all the possible ABIs of the targets and

ensuring enough information is provided so that the final to-native compilation stage can resolve everything, so it’s more like "bitcode able to accommodate

all the listed targets" rather than “bitcode that’s target independent”.

HTH,

Dave

Hi David,

Thank you for your reply.

In fact, my question originally came from the google native client.
I thought that the bitcode can be shared among the different targets as it inherently is.
Therefore, I used the clang to generate the bitcode to prove that my thought is right,
and I supposed that the different bitcode caused from the different versions of libraries before.

Thanks for the above answering, I know the limitations of sharing the bitcode now.

Best regards,
Kenia

2012/9/26 David Tweed <david.tweed@arm.com>


Hi,


I am interested in building some large projects to get single .bc files. Is there an easy way to do this? Or do I have to go through and understand the whole makefile script?


Thank you very much.


Andy
|

This is what LLVM’s “LTO” (Link Time Optimization) does, basically. This is triggered by building with -O4 and you’d need to use an LTO-aware linker (like gold) to handle the link step. I’m not sure how you’d actually dump out bitcode from the linker, rather than a final binary - but that’s more-or-less where you’d get involved.

I realize this is a bit vague (as I’m by no means an expert on the matter) but thought it might be at least a pointer to some ideas/approach.

  • David

Instead of using linker, you can call all .o files and process them - when building with -O4 they contain bitcode.

Hi all

is it possible to avoid the emission of metadata information by opt and/or clang?

For instance, I would like to go without "tbaa" metadata in LLVM assembly code as printed by "-emit-llvm".

I'm using the 3.1 binary release for MinGW (and for Linux on a different machine).

Best regards
Nikolaos Kavvadias

You can turn off TBAA metadata by passing -fno-strict-aliasing to clang. You can turn off emitting debug metadata by not passing -g. There is no flag for turning off metadata in general (for example, range metadata will still be produced for certain casts, and if you compile Objective-C for the GNU runtimes then you will still have some metadata attached to message sends. If you want to remove all metadata, then you will need to strip it off explicitly, but that leads to the question of what problem you are actually trying to solve.

David

Hi David

thanks for your answer.

You can turn off TBAA metadata by passing -fno-strict-aliasing to clang.

This eliminates the emission of "tbaa" metadata when compiling C code. Not sure if this covers all cases for C compilation.

I'm just working on a flex/bison LLVM grammar. I understand that since the 2.6 (or something) release, LLVM code base has switched to a handwritten parser.

Anyway this is just a parsing test, nothing more for the moment.

Best regards,
Nikolaos Kavvadias
http://www.nkavvadias.com