Re: -fvar-tracking-assignments initial patch set

[Alexandre Oliva <aoliva at redhat dot com>]

On Oct  2, 2007, "Richard Guenther" <richard.guenther@gmail.com> wrote:

> Can you do a short write-up on what issues the branch will solve and how
> it does so?

1. annotate source-level assignments such that we can keep track of
where the value of variables are, even after optimizations.

2. ensure the annotations don't modify the generated code (I'm still
working on this throughout the x86_64-linux-gnu libs, even though
bootstrap-debug already passes; I'm thinking of adding a
bootstrap-debug-lib, and extending the compare target to compare all
host directories, rather than only gcc)

3. change var-tracking so as to take better advantage of the generated
code.  My plan is to use some modified cselib, rather than the current
micro-ops, to get a better picture of locations where vta-able
variables are maintained (copies introduced by optimizations, register
allocation, etc, that are not reflected in annotations), while still
using the REG and MEM locators otherwise.  The idea is to attach a
list of trees (variable decls or components thereof) to equivalent
expression lists, and then use dataflow analysis to globalize these.

4. avoiding changes to generated code has so far required some very
conservative clean-up operations that pretty much discard all useful
information in the annotations (e.g., when a register is dead at the
point of the annotation, we must remove the annotation, lest it will
keep the register live; there's something similar in the tree-ssa IR).
Over time, we shall modify optimization passes such that they adjust
annotations when viable, such that the conservative fallbacks don't
hit as often.  There are a bunch of other ??? FIXMEs in the patches in
the branch about places where I realized we could do better but didn't
do that yet.  IIRC the only pass in which I actually did something for
the sake of preserving the annotations during transformations was
combine.

5. experiment with lists of locators, rather than a single location
per variable, such that, right after an assignment, we can take note
of both the assigned-to variable and the expression it's assigned
from.  This might enable us to retain more information.

6. It probably makes sense to distinguish "variable location" (lvalue)
from "available copy of the variable's value" (rvalue).  Although I'm
not sure how to represent this in debug info, we should prefer lvalue
locations over rvalue locations when emitting debug info, since it
would be bad for a user to assign to an rvalue location that happens
to contain a copy of the intended variable's value, but that is
actually the location of a different variable, thus changing the
program behavior in unintended ways.

> I am going to prototype what I had in mind to see if it is viable
> and do a writeup of that approach as well.

Thanks,

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}