[cfe-commits] Patch to clang -emit-llvm-bc on Linux

[Daniel Dunbar]

On Thu, Apr 30, 2009 at 9:08 AM, Collin Winter <collinwinter at google.com>wrote:

> Hi Daniel,
>
> On Wed, Apr 29, 2009 at 7:24 PM, Daniel Dunbar <daniel at zuster.org> wrote:
> > Hi Colin,
> >
> > I would definitely like to improve this, but I also think that the
> llvm-gcc
> > behavior (which clang is just copying) was chosen by design. Poor design,
> > perhaps, but I believe the intent was that -emit-llvm simply changes the
> > output format, not the functionality. Thus -S -emit-llvm is output in
> LLVM
> > IR, -c -emit-llvm is output in LLVM bitcode, -emit-llvm alone is an
> > executable, but having been compiled with LLVM tools. The problem, of
> > course, is when the linker doesn't have LLVM support.
> >
> > I'd rather not break "compatibility" with llvm-gcc... is there a specific
> > reason you wante to change this (why not use "-c"?). If it just comes
> down
> > to eliminating the current bad user experience, we could augment the tool
> > chain to understand whether the system supports LLVM inputs and avoid
> trying
> > to pass them to the linker and give an error instead.
>
> My biggest reason for wanting to change this is that clang
> -emit-llvm-bc works as expected on Darwin but works differently on
> Linux. This recently broke our project's build: testing the change on
> our Darwin laptops worked just fine, but broke our Linux-based
> buildslaves. We can certainly use -emit-llvm -c going forward, but the
> difference between platforms seems like a bug.


I'm a little confused, I missed in the original email that you are using
"-emit-llvm-bc". This argument isn't understood by clang or llvm-gcc.
"emit-llvm-bc" is the low level CC1 argument, but it shouldn't be something
the user sees.

I am going to augment the tool chains for the time being to have a clue
about whether the linker supports LLVM inputs, and refuse to call it if it
doesn't. This won't make -emit-llvm work on Linux, but it will at least have
a nicer error message. In the long term we would want this to be tied to
whether or not the linker has Gold + LTO support.

 - Daniel

Note that currently in clang, -emit-llvm-bc -c doesn't work:
>
> obj/$ Util/llvm/Debug/bin/clang -ccc-echo -O3 -c -emit-llvm-bc  -I.
> -IInclude -I../trunk -I../trunk/Include   -DPy_BUILD_CORE
> ../trunk/Python/llvm_inline_functions.c -o
> Python/llvm_inline_functions.bc
>  "/usr/local/google/collinwinter/us/obj/Util/llvm/Debug/bin/clang-cc"
> -triple i386-unknown-linux-gnu -S -disable-free -main-file-name
> llvm_inline_functions.c --relocation-model static --disable-fp-elim
> --unwind-tables=0 --fmath-errno=1 -DPy_BUILD_CORE -I. -IInclude
> -I../trunk -I../trunk/Include -O3 -fdiagnostics-show-option -o
> /tmp/cc-X0bB5X.s -x c ../trunk/Python/llvm_inline_functions.c
>  "/usr/bin/gcc" -O3 -emit-llvm-bc -I. -IInclude -I../trunk
> -I../trunk/Include -DPy_BUILD_CORE -c -o
> Python/llvm_inline_functions.bc -x assembler /tmp/cc-X0bB5X.s
> obj/$ file Python/llvm_inline_functions.bc
> Python/llvm_inline_functions.bc: ELF 32-bit LSB relocatable, Intel
> 80386, version 1 (SYSV), not stripped
>
> clang -emit-llvm -c produces the bitcode as expected, though. I'll
> change our build steps to use -emit-llvm -c.
>
> Thanks,
> Collin Winter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20090502/583822a8/attachment.html>