------- Additional Comments From amacleod at redhat dot com 2005-02-03 14:37 ------- (In reply to comment #23) > We have incomming into out-of-ssa, > > x.1 = exp1 > x.2 = x.1 + exp2 > x.3 = x.2 + exp3 > > We're currently allowing TER to produce > > x.3 = exp1 + exp2 + exp3 > > What if we were to disable TER substitution when the base variable on the lhs > matches the base variable on the rhs? So in this case we'd notice x.1 and x.2 > have the same base variable and not merge. And (more importantly) so forth so > that the definitions of x.20 and x.19 aren't merged either.
of course, the real issue isnt just the root variable is it? We could have TER introduce an expression with 1000 different base variables in the expression, and the problem is that we've got 1000 live now instead of something a little more sane by accumulating along the way. IN the above example, it depends on what is in exp1, exp2 and exp3 as to whether you want to avoid the subsitution. if all 3 exp's end up equating to y.6 + y.6, you probably DO want to let it happen so you end up with x.3 = y.6 + y.6 + y.6 + y.6 + y.6 + y.6 > This can probably still fall down, especially when a lot of our variables get > replaced by "ivtmp.x" and "pretmp.y", but at least we'll have some cut off > that > handles accumulation naturally. Perhaps there's some loser notion of "base > variable" we can use, like "in the same partition", or something. The partitions have been decided by the time TER runs, so we know what SSA_NAME is going to be a different variable and what isn't. all you need to do is compare var_to_partition(ssa_name) to see if they are in the same partition number. I suspect that anything easy we can do will have performance slow downs if we do it at >=-O2, but you never know :-). I suspect the better solution is to limit the number of live ranges it can introduce to something sane. I dont think that is likely to be too hard to code, the question is how quickly can it run :-) At every expression replacement point, we'd have to make a quick run through the operands and count unique partitions. Are we looking to do this at -O2 as well? I guess thats a key question. at just -Os, it might very well be sufficient. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17549
