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.
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.
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.
>
>
>
>>
>>>
>>>>
>>>> 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.
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 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.
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.