Re: Live range splitting in new allocator

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    > That's my personal opinion too, but gcc has long had the rule that the
    > presense or absense of "-g" should not affect code generation, only
    > debugging information. And too many people seem to think that "-O2 -g"
    > is a valid combination and should be debuggable.

    Isn't this coming, originally, out of a policy decision?

Yes, but for very strong technical reasons.  The concern is the
so-called "Heisenbug", a bug that goes away when you try to look for
it.  If -g can change the code *at all*, it might make a bug appear to
go away so that it can no longer be found.

    I've wondered about this a little in the past and had it explained to
    me that this is actually a side effect of a conscious decision to have
    the default installation for all GNU software be debuggable, 

No, that's wrong.

    Because giving up optimization to achieve this goal would result in
    slower and measurably poorer software, 

You misunderstand.  The issue isn't giving up optimization.  That's
totally orthogonal.  The issue is just that -g should not affect what
optimizations are done: nothing more.  It's perfectly reasonable to
consider optimizations that make debugging harder, but they should be
controlled with sweitches *other* than -g.