VTA merge?

[Alexandre Oliva]

On Jun  8, 2009, Diego Novillo <dnovillo@google.com> wrote:

> - Performance differences over SPEC2006 and the other benchmarks
>   we keep track of.

This one is trivial: none whatsoever.  The generated code is the same,
and it *must* be the same.  Debug information must never change the
generated code, and VTA is all about debug information.  There's a lot
of infrastructure to ensure that code remains the unchanged, and
-fcompare-debug testing backs this up.  It doesn't make much sense to
run the same code twice to verify that it performs the same, does it?
:-)


> Do all these comparisons against mainline as of the last merge
> point.

I'll start performing the other measurements you requested.  Please be
patient, it will take some time until I figure out how to use the
scripts you pointed at me and locate the code bases.

For the measurements, I won't use the last merge, but rather the trunk
(in which most of the infrastructure patches were already installed,
with minor changes) vs trunk+the posted patchset.  Or maybe I'll do
another merge into the branch, so that we have exact revisions in the
SVN tree to refer to.  I hope you don't mind that I make the tests in a
slightly different tree (it's easier for me, and shouldn't make any
difference for you), but if you insist, I'll do exactly what you
suggested.


> I would like to have a set of criteria or guidelines of what should a
> pass writer keep in mind to make sure that their transformations do
> not butcher debug information.

I've already written about this.  Butchering debug information with this
design is very hard.  Basically, you have to work very hard to break it,
because it's designed so that, unless you actively stop transformations
that are made to executable code from also applying to debug
annotations, you'll keep it up to date and correct.

What needs to be taken care of is something else: avoiding codegen
differences.  This means that whatever factors you use to make decisions
on whether or not to make a transformation shouldn't take debug
annotations into account.  E.g., if you count how many references there
are to a certain DEF, don't take the debug USEs into account.  If you
count how many STMTs there are in a function or block to decide whether
to inline it or duplicate it, don't count the annotations.

And then, in the cases in which an transformation is made when there is
only one (non-debug) reference to a name, it is probably useful to
update any debug insns that refer to that name.  If you don't, debug
info will be less complete, but still correct, at least in SSA land.  In
post-reload RTL it's more important to fix these things up, otherwise
you might end up with incorrect debug info.

That's all.  Doesn't sound that bad, does it?

> From what I understand, there are two situations
> that need handling:

> - When doing analysis, passes should explicitly ignore certain
>   artifacts that carry debugging info.

Yup.  This is where most of the few changes go.  If you fail to do that
where you should, you get -fcompare-debug errors or slightly different
code.

> - When applying transformations, passes should
>   generate/move/modify those artifacts.

Only in very rare circumstances (1- or 0- refs special cases) do they
need special attention.  In nearly all cases, because of their nature,
they're correctly updated just like the optimizer would have to do to
any other piece of code.

> Documentation should describe exactly what those artifacts are
> and how should they be handled.

Are the 3 paragraphs above clear enough?

When in the documentation do you suggest this should go?

> - What percentage of code in a pass is dedicated exclusively to
>   handling debug info?

In nearly all of the tree passes, it's one or two lines per file, if
it's that much.  In RTL it's sometimes a bit more than that.

> - What is the point of diminishing returns?  If I write 30% more
>   to keep track of debug info, will the debug info get 30%
>   better?

See below.

> - What does it mean for debug info to be 30% better?  How do
>   we measure 'debug info goodness'?

I don't know how to measure “30% better” debug info.  Do you have a
criterion to suggest?

I see at least two dimensions for measuring debug info improvements:
correctness and completeness.  Currently we suck at both.

VTA's design is such that the infrastructure work I've done over its
development addresses teh correctness problem once and for all.  The
remaining improvements are in completeness, and those are going to be
(i) in the var-tracking pass and debug info emitters, that still can't
or don't know how to use all the information that reaches them, and (ii)
in passes that currently discard or invalidate debug annotations (so
that variables end up marked as optimized out), but that could retain it
with a bit of additional work.  I don't have any actual examples of
(ii), I'm only aware of their theoretical possibility, so I can't
quantify additional work required for that.  That said, the additional
work would be explicitly optional, and certainly not necessarily taken
up by the maintainer of the pass, but rather by someone interested in
debug information.


> - Does keeping debug info up-to-date introduce algorithmic
>   changes to the pass?

For passes that make changes regardless of how many references there are
to names, no changes whatsoever are required.  Debug annotations will be
updated just like any other pieces of code.

For passes that make changes for boundary cases (say 1 or 0 references),
it is useful (but only mandatory post reload) to modify the algorithm to
also update any other debug stmts/insns that refer to the modified item.


> Clearly, if one needs to dedicate a large portion of the pass
> just to handle debug information, that is going to be a very hard
> sell.

Agreed.  That's why it was designed to be absolutely trivial.  All the
-fcompare-debug debugging strongly supports that it is so.

-- 
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