On 11/16/2015 10:36 AM, Ajit Kumar Agarwal wrote:
For Induction variable optimization on tree SSA representation, the
register used logic is based on the number of phi nodes at the loop
header to represent the liveness at the loop. Current Logic used only
the number of phi nodes at the loop header. Changes are made to
represent the phi operands also live at the loop. Thus number of phi
operands also gets incremented in the number of registers used.
But my question is why is the # of PHI operands useful here. You'd have
a stronger argument if it was the number of unique operands in each PHI.
While I don't doubt this patch improved things, I think it's just
putting a band-aid over the problem.
I think anything that just looks at PHIs or at register liveness at loop
boundaries is inherently underestimating the register pressure
implications of code motion from inside to outside a loop.
If an object is pulled out of the loop, then it's going to conflict with
nearly every object that births in the loop (because the object being
moved now has to live throughout the loop). There's exceptions, but I
doubt they matter in practice. The object is also going to conflict
with anything else that is live through the loop. At least that's how
it seems to me at first thought.
So build the set of objects (SSA_NAMEs) that either birth or are live
through the loop that have the same type class as the object we want to
hoist out of the loop (scalar, floating point, vector). Use that set of
objects to estimate register pressure.
It won't be exact because some of those objects could end up coloring
the same. BUt it's probably still considerably more accurate than what
we have now.
I suspect that would be a better estimator for register pressure as far
as LICM is concerned.
jeff
