Loss of guard information inhibits optimizations under -ecc/-check c/-doawlf
|
|
Bugzilla Link |
1060 |
Created on |
Apr 12, 2013 23:04 |
Version |
svn |
OS |
Linux |
Architecture |
PC |
Extended Description
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.