[LLVMdev] Disabling certain optimizations at -O1?

David Tweed david.tweed at gmail.com
Thu Nov 28 05:31:44 PST 2013


On Thu, Nov 28, 2013 at 1:11 PM, Renato Golin <renato.golin at linaro.org>wrote:

> On 28 November 2013 00:00, Robinson, Paul
> <Paul_Robinson at playstation.sony.com> wrote:
> > In my experience, to a first approximation, anything
> > that changes the CFG or that reorders generated code beyond source
> > statement boundaries is likely to make things more difficult for the
> > debugger.
>
> I agree.
>
>
> > Okay.  I worked on compilers where -O1 was the default, actually, and
> > it was "generally fast enough" but still very easy to produce very
> > good debug info.
>
> Me too, but if you search the meaning of that, it's actually to
> maintain the debug illusion. You want to make it simple enough for the
> user, the default should be a local minimum for all three functions:
> speed, simplicity, debugability.
>

I'm not sure where the simplicity came in, nor why it's a particularly
important goal for debugging. (Clearly making it excessively "not simple"
would be bad, but if I'm trying to debug something having it be simple to
set-up/invoke isn't particularly important. Indeed, a most of the bugs
which really need a debugger are manifest in big applications where even a
non-debug build can be very "not simple".)

On the other hand, deciding on the precise trade-off between execution
speed and "interpretability of machine states in terms of the original
source" is indeed a significant problem for "source level" bugs which
manifest after a huge number of instructions have been executed (either
because the program is big, or it runs intensively before hitting the bug).

-- 
cheers, dave tweed__________________________
high-performance computing and machine vision expert: david.tweed at gmail.com
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131128/22e2a287/attachment.html>


More information about the llvm-dev mailing list