changing -save-temps to keep bitcode?

We spend a lot of time investigating clang bug reports, often with users who aren’t very comfortable working from a command line. One approach that often works well when we need to collect more information is to request that they build with -save-temps and then provide the resulting preprocessed source and assembly code. I’d like to extend that to also include the bitcode. That gives us a really easy way to collect the information we need to triage a bug report. It would also help identify issues where writing the bitcode to a file changes the results. That isn’t supposed to happen, and Duncan’s recent work to preserve the use-list order in the bitcode helps a lot, but I’m pretty sure there are still cases where it happens.

Does anyone have interest in this or objections to it?

The changes to implement it should be straightforward. The -save-temps option would cause the driver to run the cc1 phase with -emit-llvm, and then the driver would need a new “Backend” action to compile the bitcode file. The Backend action would be used only with the -save-temps option, in the same way that the existing Assemble action is treated when using the integrated assembler.

Yes, please. Especially if it captures the bitcode *before* any of the
optimisations hit.

Joerg

Agreed. On several occasions, I've found myself wondering how I can generate bitcode exactly as it leaves the parser, before any early cleanups and such.

Diego.

Does anyone have interest in this or objections to it?

Yes, please. Especially if it captures the bitcode *before* any of the
optimisations hit.

Agreed. On several occasions, I've found myself wondering how I can
generate bitcode exactly as it leaves the parser, before any early cleanups
and such.

-mllvm -disable-llvm-optzns

will produce the IR straight out of Clang's CodeGen. Skipping things like
the AlwaysInliner and AddDiscriminator pass, etc.

Yep. It's possible to do this with '-emit-llvm -mllvm
-disable-llvm-optzns', but this is way harder than just -save-temps. If
-save-temps makes .s files that aren't part of normal compilation, we can
afford to make .ll files that aren't part of normal compilation.

Yes. Of course, i know that. The point is that easier is better.

Diego.

>
>
>
>>
>>>
>>>>
>>>> Does anyone have interest in this or objections to it?
>>>
>>>
>>> Yes, please. Especially if it captures the bitcode *before* any of the
>>> optimisations hit.
>>
>>
>> Agreed. On several occasions, I've found myself wondering how I can
generate bitcode exactly as it leaves the parser, before any early cleanups
and such.
>
>
> -mllvm -disable-llvm-optzns
>
> will produce the IR straight out of Clang's CodeGen. Skipping things
like the AlwaysInliner and AddDiscriminator pass, etc.
>

Yes. Of course, i know that.

Ah, sorry - wasn't sure if you knew that particular one. I always forget
it/have to look it up whenever I want to do that.

The point is that easier is better.

Sure enough - well, point to Bob, then: consider doing this kind of IR,
rather than the usual -emit-llvm IR, to get something closer to the
original/pure generated IR.

- David

Sounds good. I agree that will be even more useful. Steven Wu has already written a patch to do something similar, so I’ll see if I get that done soon.

I’ve committed a change to implement this in r224503. Please try it out and let me know if it is not doing what you expect.

I had to revert this patch in r224546, as it broke compilation of fortran files with gcc through the clang driver. It’s easy to observe the change in behavior with -###, but I think you need to be on a system where clang thinks there is a valid gcc installation that can handle fortran. I was unable to observe the behavior change on Windows, for example, so I doubt it will be observable on Mac OS X without some fiddling. Let me know if you need help reproducing the situation.

Do you have any details on how it broke? If I can see the symptom, I might be able to guess at the cause.

It’s all visible with -### on a system with gcc installed. Previously we would invoke gcc to do the compilation for .f files, and with this change we would try to invoke clang. I haven’t dug further than this.

Before:

$ clang -c t.f -###
clang version 3.6.0 (trunk 224546) (llvm/trunk 224542)
Target: x86_64-unknown-linux-gnu
Thread model: posix
 "/usr/bin/gcc" "-S" "-m64" "-o" "/tmp/t-22d130.s" "-x" "f95" "t.f"
 "/usr/local/google/home/rnk/llvm/build/bin/clang-3.6" "-cc1as" "-triple" "x86_64-unknown-linux-gnu" "-filetype" "obj" "-main-file-name" "t.f" "-target-cpu" "x86-64" "-mrelax-all" "-o" "t.o" "/tmp/t-22d130.s"

After:

$ clang -c t.f -###
clang version 3.6.0 (trunk 224546) (llvm/trunk 224542)
Target: x86_64-unknown-linux-gnu
Thread model: posix
 "/usr/local/google/home/rnk/llvm/build/bin/clang-3.6" "-cc1" "-triple" "x86_64-unknown-linux-gnu" "-emit-obj" "-mrelax-all" "-disable-free" "-main-file-name" "t.f" "-mrelocation-model" "static" "-mthread-model" "posix" "-mdisable-fp-elim" "-fmath-errno" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-fuse-init-array" "-target-cpu" "x86-64" "-dwarf-column-info" "-coverage-file" "/usr/local/google/home/rnk/llvm/tools/clang/t.f" "-resource-dir" "/usr/local/google/home/rnk/llvm/build/bin/../lib/clang/3.6.0" "-fdebug-compilation-dir" "/usr/local/google/home/rnk/llvm/tools/clang" "-ferror-limit" "19" "-fmessage-length" "190" "-mstackrealign" "-fobjc-runtime=gcc" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-o" "t.o" "-x" "f95" "t.f"

Works for me, thanks!

I would add a driver test, but it requires adding a new full sysroot to test/Driver/Inputs. =/