> Oh, I was looking for a rationale for the restriction to constant-ness > (and specifically - off my head, without rechecking the patch - data > structure limitations from that decision). So yes, we can restrict > to constants, but can we keep the infrastructure in a way that we > _could_ allow non-constants? Like maybe SSA default defs > (parameter values)?
Thought about this for some time and while it wouldn't be too much work to fit in non-constant factors, I'm not sure it's really worth it. What I'd really like to avoid is (a + b) * (c + d), so maybe we should keep the non-constant factors as SSA names and not descend into them. The hash_map would would need pair<constant, SSA name> as key or similar, that's doable. Costing is another matter but as long as we reject the transform when there are more multiplications than before, I suppose we're still good. So the current shape is not fully unsuitable (it's not that much code anyway) and we could add variable-factor handling, but I'd rather not :) If necessary, I'd not go deeper than one level as said above. -- Regards Robin
