Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • sac2c sac2c
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 334
    • Issues 334
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 14
    • Merge requests 14
  • Deployments
    • Deployments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Infrastructure Registry
  • External wiki
    • External wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • sac-group
  • sac2csac2c
  • Issues
  • #1060

Closed
Open
Created Jan 12, 2010 by Robert Bernecky@rbeDeveloper

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.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking