On Fri, Aug 30, 2013 at 09:49:59AM -0700, Easwaran Raman wrote:
> Yes, this is pretty much what I was proposing. The current
> implementation doesn't rely on UIDs being unique - they only have to
> be monotonically non-decreasing. So, when a UID of 0 is encountered,
> go up till a non-zero UID is found and then go down and assign this
> non-zero UID. This effectively implies that each UID-0 stmt is visited
> at most twice. I don't think we need to check if I see more than
> certain number of UID-0 stmts and redo the entire BB.
Sure, renumbering the entire BB would be only for compile time reasons;
if you end up with a huge bb where 90% of stmts will have the same UID,
it is as if you weren't using UIDs at all and always walked the entire BB
to find out what stmt precedes what. You could spend a lot of time in
appears_later_in_bb.
Looking at the code, couple of nits:
return ((bb_a == bb_b && gimple_uid (a) < gimple_uid (b))
extra space before <.
gsi_next (&gsi);
if (gsi_end_p (gsi))
return stmt1;
for (; !gsi_end_p (gsi); gsi_next (&gsi))
{
...
}
return stmt1;
Why not just for (gsi_next (&gsi); !gsi_end_p (gsi); gsi_next (&gsi)) ?
The extra if (gsi_end_p (gsi)) return stmt1; doesn't make any sense
when the loop does exactly that too.
And for the debug stmts, are you sure you are resetting only those debug
stmts which you have to reset? I mean, if there are say debug stmts using
the SSA_NAME in other bb, it doesn't need to be reset (unless you reuse
the same SSA_NAME for something else), and the compiler even has code
to reconstruct SSA_NAMEs that have been removed, but were still referenced
in debug stmts, using expressions in debug stmts and debug temporaries.
Jakub
