This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tcb]: Add RHS to V_MUST_DEF


On Sun, 2004-10-03 at 21:48, Daniel Berlin wrote:
> On Fri, 2004-10-01 at 14:48 -0400, Andrew MacLeod wrote:
> > On Fri, 2004-10-01 at 14:34, Daniel Berlin wrote:

> > 
> > 
> > I was thinking about how we show MUST_DEF too. Purely a reading nit, but
> > I wonder if we would be better off printing it as,
> > 
> > V_MUST_DEF <a_3> , V_KILLS <a_2>
> > 
> > or some such thing.  Someone else probably has a better idea.
> > 
> > No functional difference, but makes it much clearer we are looking at a
> > MUST def and not a MAY def. It also removes the implication that a_2 has
> > something to do with a_3.
> > 
> 
> Assuming i do that, is the patch okay for tcb?

Well, looking at the patch, I have a new concern that I didn't realize.

Marking variables for renaming in DCE is an unacceptable hit I think.
DCE is nice and quick, that will have a potential impact I dont think we
really want.

Let see if I understand the problem

a_2 = PHI <a_1, a_6...>
...
# VUSE <a_2>
S1;

#V_MUST_DEF <a_9>, V_KILL <a_2>
S2;

We discover that S1 is a dead stmt, so we remove it.  a V_KILL isn't a
use, so that doesn't keep the PHI live. so we remove it. Now what do we
do with the V_KILL of a_2.

In this case, either we don't remove the PHI, or we rename 'a'.

I dont think renaming 'a' is a good idea, that could result in a big
compile time hit.

Not deleting the PHI is probably not a good idea either, since it could
keep a Basic block around for no real good reason.

The problem is similar for V_MAY_DEFS, only not quite as dramatic:
# b_2 = V_MAY_DEF <b_1>
S1;

# V_MUST_DEF <b_6>, V_KILL <b_2>
S2;

If we remove S1 then we would replace V_KILL <b_2> with the RHS of the
maydef, leaving:

# V_MUST_DEF <b_6>, V_KILL <b_1>
S2;

Of course, that requires immediate_uses information, which , at the
moment, isnt freely available, although it will be.

That still leaves us with the PHI problem.

Have you thought of any other solutions?  Im just realizing this now, so
I havent had time to consider it yet.  I think I might like Diego hacky
solution of looking at the base variable for code sinking if we have to
do this.

Blah.

Andrew


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]