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 Mon, 2004-10-04 at 08:05, Andrew MacLeod wrote:
> 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.
FWIW, DSE has to solve the same core problem.  Luckily we have 
immediate use information in DSE and it's pretty easy to fix up
the RHS of the V_{MAY,MUST}_DEF operands.

jeff



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