Loss of guard information inhibits optimizations under -ecc/-check c/-doawlf
|Created on||Apr 12, 2013 23:04|
This is a problem that arises from time to time, and I just ran into another case of it, in the CF unit test SAACFprf_reshapeAKD.sac. The code of interest is this: v = id(100); vec1 = iota(v); vec2 = _reshape_VxA_( [v], vec1); [Replacing [v] by _shape_A_(vec1) changes nothing here, BTW.] We end up with this IL (-doawlf -ecc): Vec1 = [ v ]; v2, p = _non_neg_val_S_( v); Vec3 = [ v2 ]; if( Vec1 == Vec3) --> optimize I need to prove that V1≡V3, if I am to remove the reshape. The guard is introduced by the inlining of iota(), so the code as it stands is correct, in the sense that we don't have any CSE/VP/CP sort of problems. I was looking for a PMly way to do the V1≡V3 check, but that's local, in the sense that I'd need to insert them anywhere I need to make such a check. A superior approach might be a traversal that, within each basic block moves guards upwards until they reach the definition point of their arguments. That would give us: v2, p = _non_neg_val_S_( v); Vec1 = [ v2 ]; Vec3 = [ v2 ]; if( Vec1 == Vec3) --> optimize This would work fine in the above case, but it is not a perfect solution, inasmuch as we may have a guard such as: _shape_matches_dim( X, Y) and have some rubbish between the definition points of X and Y. Nonetheless, it is fairly easy to implement (the last paragraph being the hardest part), and would probably get us 90% of the way there. Better ideas welcome.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information