<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 15, 2014 at 1:09 PM, Diego Novillo <span dir="ltr"><<a href="mailto:dnovillo@google.com" target="_blank">dnovillo@google.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 12/15/14 15:10, Joerg Sonnenberger wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Dec 15, 2014 at 11:26:43AM -0800, Bob Wilson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Does anyone have interest in this or objections to it?<br>
</blockquote>
<br>
Yes, please. Especially if it captures the bitcode *before* any of the<br>
optimisations hit.<br>
</blockquote>
<br></span>
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.</blockquote><div><br></div><div>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.</div></div></div></div>