Catch-22: LIR won't lift
Bugzilla Link | 1022 |
Created on | Sep 11, 2012 22:32 |
Version | svn |
OS | Linux |
Architecture | PC |
Extended Description
I just traced an AWLF failure partway back to this loopfun code: int loopfun( int _lacs_2325) { ... _uprf_1573, _uprf_1574 = _non_neg_val_S_( _lacs_2325); loopfun( _uprf_1573); There are two distinct problems here: a. LACS won't propagate AVIS_MINVAL( _lacs_2325) = 0 into the loopfun, because the variable is not loop-invariant. b. DLIR won't lift the guard expression out of the loopfun, for the same reason, I think. As I write this, I realize that, in this particular case, I may be able to resolve the issue this enhancement to LACS: In the calling environment, _lacs_2325 has AVIS_MINVAL = 0; In the recursive call, _uprf_1573 has AVIS_MINVAL = 0. In that case, LACS can happily set AVIS_MINVAL( _lacs_2325) = 0, and the code should get better. However, I suspect this is not the case in general, so welcome ideas on better ways to tackle this problem. sac2c -V sac2c v1.00-beta (Haggis And Apple) developer rev 18218:MODIFIED linux-gnu_x86_64 (Tue Sep 11 16:07:19 EDT 2012 by sac) cd ~/sac/testsuite/optimizations/lacs$ sac2c simpleLoopAKD.sac -bopt:saacyc:lof:5 -doawlf -nowlf -v1 -#d,LIR,WLIR,DLIR &> crud