> It would be nice if it worked this way, but the dozens of patches to fix
> -g/-g0 compile differences I posted over the last several months show
> it's really not that simple, because the codegen IR does not tell the
> whole story.  We have kind of IR extensions for debug info, for types
> and templates, for aliasing information, even for GC of internal data
> structures, and all of these do affect codegen, sometimes in very subtle
> ways.

Yes, precisely, they are IR extensions, most passes shouldn't have to bother 
with them.  Fixing bugs there can probably be done once for all passes.

> Speaking specifically of debug information, the little attention given
> to preserving information needed to generate correct debug info means
> that introducing errors is not just a matter of active mistakes.  Most
> of the debug information errors we have now do not follow from actively
> breaking debug info data structures, but rather from passively failing
> to keep them up to date, or even missing data structures to that end.

I was only talking about code generation, not debug info generation.

> I can certainly understand the wish to keep debug info IR out of sight,
> and have it all be maintained sort of by magic, without need for
> developers to even think about it.  While I share that wish and even
> tried to satisfy it in the design, I've come to the conclusion that it
> can't be done.  And it's not just a “it can't be done without major
> surgery in GCC as it is today”, it's a “it can't be done at all”.

Well understood.  So, in the end, we seem to agree that your approach is 
fundamentally different from what we have now.  I only added that in my 
opinion it is inherently less robust as far as -g vs -g0 code is concerned 
(unless it is enabled unconditionally) and we shouldn't trade this loss of 
robustness for nothing.

-- 
Eric Botcazou

Reply via email to