> 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