WLCSB (etc.!) interaction with extrema unfortunate

Bugzilla Link	668
Created on	Jan 12, 2010 21:04
Version	svn
OS	Linux
Architecture	PC
Attachments	cblockFailAKS.sac

Extended Description

Created an attachment (id=659)
Source code to reproduce fault
I just came across this, in Build #16725:16727:MODIFIED.
sac2c cblockFailAKS.sac  -nowlf -noawlf -extrema -b11:saacyc:wlbsc:1  >crud
  BB = with {
        (_flat_2 <= iv=[i] < _flat_5 genwidth [ 50 ])
        {
          _ivexi_578 = _attachextrema_( iv, _flat_2, _flat_5);
          _ivexi_585_i = _attachextrema_( i, _ivexi_581__flat_2, _ivexi_584__flat_5);
          _dup_586__mse_285__esd_187 = [:int];
          _dup_587__isaa_284_NONO = _ivexi_578;
          _wlbsc_655_sc_iv = [ 0 ];
          _wlbsc_656_sc_e = i;
          _wlbsc_657_sc_bound = [ i ];
          _wlbsc_652_sc_iv = [ 0 ];
          _wlbsc_653_sc_e = i;
          _wlbsc_654_sc_bound = [ i ];
          _dup_588_NONO = with {
                (_flat_2 <= _dup_589__pinl_130__flat_6=[_dup_590__pinl_131_i] < _wlbsc_657_sc_bound genwidth [ _ivexi_585_i ])
                {
                  /* empty */
                } : _dup_590__pinl_131_i ;
 } :
              genarray( _wlbsc_657_sc_bound, _esd_187);
          _dup_591__pinl_142__flat_95 = _sel_VxA_( _ivexi_578, _dup_588_NONO);
        } : _dup_591__pinl_142__flat_95 ;
 } :
      genarray( _flat_5, _flat_1);
The idea behind the _attachextrema in the WL body was to get around
problems with non-SSA treatment of WITH_IDs across multiple WL partitions.
However, any optimization that introduces new references to 
WITH_IDs is likely to get them wrong, by grabbing, in this case, i,
instead of _ivexi_585_i.
I do not have any proof that this is causing performance loss (yet).
I just stumbled across it while eyeballing IL code.
However, it may be that we have to resurrect SSAIV, and make
all WL partition WITH_IDS unique. Ideas welcome. 
Another choice would be a kludge that goes rummaging through
the code block looking for the appropriate F_attachextrema(). Ugh.
I've marked this as normal priority, because (a) fixing it is likely not
easy, in general, and (b) I haven't seen any performance problems
caused by it. Yet.