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.