https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #34 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Jakub Jelinek from comment #33) > (In reply to Andrew Macleod from comment #32) > > We could in theory expand it to look at 2 levels if its a single operand... > > Yeah, that would help here and could be worth it. > > > which will help with some of these cases where there are casts, and keep the > > performance degradation from being too bad. I'm sure there will be cases > > where a third would be handy :-P > > And/or, could we go from seeing zone1_12 in an PHI arg and in that case walk > a level or two or three to see if it is dependent on an SSA_NAME known to > have specific range on the edge and if so, do those range queries using that > range? well, its knowing it has a specific ranges that is the not-cheap part. For every one we find a useful range, therea re likely many queries that do not fina anything useful. and every level of indirection adds to that. So we know zone1_12 uses _2, we can see that it is a recomputable value, but without outgoing edge values cached, we have to actually calculate it. Until we calculate it, we dont know that its going to help us.. we just know it *can* be recomputed, not that its useful. Even if we limited it to just PHI arguments (which specializing is not easy btw), that means every PHI argument could have additional 2nd level checks and recomputations, many of which are not useful. I will poke at whether its possible to cheaply handle a second (or third) level for single dependency defs.
