Re: GCC 3.5 Status (2004-08-29)

[Daniel Berlin <dberlin at dberlin dot org>]

> >  I am confident that there
> > are alternatives that, while perhaps less comprehensive, get enough of
> > the common cases to achieve most of the benefits.
> 
> What is your confidence based on?  What common cases?  Did Dan tell you
> about the issues that he's fighting?  No "less comprehensive" solution
> exists that will not run into the exact same problems.
> 

I didn't tell him about the issues i'm fighting, so he's probably just
stating the typical result, ie "It takes less time to get the common
cases than it does to get all the cases".

Of course, the issues i'm dealing with are things that were punted on
earlier in the design of tree-ssa, because they were either hard to get
right, we didn't have time then, etc.

Let me give an example issue from an email i sent to diego and richard,
as a motivating example.

In our current scheme of things,

x = a.f
c = a.e
a.e = 5
c = a.f

becomes

VUSE (a_1)
x_2 = a.f

VUSE (a_1)
c_3 = a.e

a_4 = V_MAY_DEF (a_1)
a.e = 5

VUSE (a_4)
c_5 = a.f

As you can see, this type of VUSE should actually be called PARTIAL_USE
or something (it was the first use of vuse, before they were actually
used for memory operands, so i blame diego for not renaming it, unless
i'm misremembering and it was introduced at the same time as memory
operands).

Knowing that a.e doesn't actually kill a.f is the *easy* part.
It's representing this that is tricky.

You can't get rid of the VUSE of a, because it's still really a partial
use.  You can't simply change the V_MAY_DEF, because that will screw up
the later partial uses.  Unless we start to talk about fitting something
radically different into our scheme, you need to do something like add
an extra set of vuses so that it becomes:

VUSE (a_1)
VUSE (a.f_1)
x_2 = a.f

VUSE (a_1)
VUSE (a.e_1)
c_3 = a.e

a.e_2 = V_MAY_DEF (a.e_1)
a.e = 5

VUSE (a_1)
VUSE (a.f_1)
c_5 = a.f


This gives you the result you want.  But of course, we don't allow
component_refs in SSA_NAMES right now. You can't simply use field_decls,
because of compatible struct problems.

Do we want SSA_NAMES of component_refs here, or do we want just offset +
size, and then let the renamer do the work of figuring out the versions
to assign as a result:

IE

VUSE (a_1, 0, 4)
x_2 = a.f

VUSE (a_1, 4, 8)
c_3 = a.e

a_2 = V_MAY_DEF (a_1, 4, 8)
a.e = 5

VUSE (a_1, 0, 4)
c_5 = a.f

(IE let it figure out that we can still reuse a_1 here, because it
hasn't been def'd).

Or do we want something else entirely not involving vuses?

The issue of "p->a" and "p->b" aliasing hand a[0] vs a[1] aliasing have
similar unresolved design issues, like what do we put in the alias
bitmaps (IE pt_vars), since none of these things have uids that are in
the same namespace as variables. Or do i just ignore the existing alias
bitmaps -> may alias conversion, and just add component_refs to the
alias varrays directly, and maximally share the component refs.  Or
something else not involving component refs?  

This is the stuff i'm counting on taking the most time.
--Dan