<div dir="ltr">On 14 January 2013 12:27, henry miller <span dir="ltr"><<a href="mailto:hank@millerfarm.com" target="_blank">hank@millerfarm.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>Would it be unreasonable to ask for a new/seperate set of optimizations: optimize debug.  This would apple agressive optimizations, but not "significantly" changing the order of the code. <br>
</div></div></blockquote><div><br></div><div style>This will be interesting, but knowing how LLVM can segfault when commenting out one or the other pass from a sequence, I'd think that it'd take a long time before we could test *every* combination of these "nice to have"  optimization profiles. Basically, you get all the tests we have today and duplicate it for each profile.</div>
<div style><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>I don't know the optimizer, but I know as a user of compilers that minimal optimization is often the difference between painfully slow program execution and okay performance. However debugging optimized programs can be difficult because the debugger jumps all over making the problem hard to understand. <br>
</div></div></blockquote><div><br></div><div style>I don't think you really need a performing debug image, though. Debuggers tend to be so slow than the performance of the image is irrelevant. Normally, the extra time is the number of breakpoints or watchpoints you have set, and not the image itself... ;)</div>
<div style><br></div><div style>--renato</div></div></div></div>