This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: VTA merge?
On Jun 7, 2009, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> 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.
But they do, and we don't mind. Just count the occurrences of
preserving/copying locations in expr trees, in insns, attributes in REGs
and MEMs. It's quite a lot.
> Fixing bugs there can probably be done once for all passes.
Unfortunately that's not how things have worked in the past. Every pass
had to be adjusted over time to stop debug info from being lost, and
Andrew says there's still a lot of work to be done just for correct line
number info, as he found out trying to stuff variable location
information into the infrastructure we used for line numbers.
On top of that, the assumption that the extensions don't require passes
to bother with them is unfortunately false. The misuse of the
extensions has caused a number of codegen bugs over time, and the
patches I posted and installed recently are only a few examples of that;
several others were posted, approved and installed along the way over
the past year or so. They weren't debug info errors, they were codegen
errors caused by existing debug info IR extensions.
Part of the problem, I think, is precisely that they were so invisible
that people often forgot their existence and their interaction, and got
sloppy about it beyond the point of rupture. That's why, in my design,
I focused on optimizing for sloppiness: if you do nothing, you still get
debug info right, and if you care only about codegen, you will notice
codegen issues if you forgot to take debug info into account where it
mattered.
> So, in the end, we seem to agree that your approach is
> fundamentally different from what we have now.
In some senses, yes. In others, it's quite the opposite.
It's no different in that it's still there, but mostly unnoticed, like
file:line information and REG/MEM attrs.
It's completely different in that, if you totally forget about it, you
don't get broken auto var location debug info, and you might actually be
reminded, during testing, that your code failed to take debug info into
account, because it caused codegen differences which you do care about.
Isn't that great?
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer