sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T20:19:50Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1062With2 full partitions but they are broken into bits2017-11-19T20:19:50ZCarl JoslinWith2 full partitions but they are broken into bits| | |
| --- | --- |
| Bugzilla Link | [672](http://bugs.sac-home.org/show_bug.cgi?id=672) |
| Created on | Jan 14, 2010 16:06 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug672.sac](/uploads/c3f693f2c8ea76...| | |
| --- | --- |
| Bugzilla Link | [672](http://bugs.sac-home.org/show_bug.cgi?id=672) |
| Created on | Jan 14, 2010 16:06 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug672.sac](/uploads/c3f693f2c8ea765a3a23ddfaf2eea83f/bug672.sac) |
## Extended Description
<pre>The attached code produces the following with2:
/********** (var.) segment 0: **********
* index domain: [ iv, 0 ] -> [ _uprf_914, 1 ]
*/
(iv => _uprf_914), step0[0] 1
(0 --> 1):
(0 -> 1), step0[1] 1
(0 --> 1): op_0
/********** (var.) segment 1: **********
* index domain: [ iv, 1 ] -> [ _uprf_914, 2 ]
*/
(iv => _uprf_914), step0[0] 1
(0 --> 1):
(1 -> 2), step0[1] 1
(0 --> 1): op_1
/********** (var.) segment 2: **********
* index domain: [ iv, 2 ] -> [ _uprf_914, 3 ]
*/
(iv => _uprf_914), step0[0] 1
(0 --> 1):
(2 -> 3), step0[1] 1
(0 --> 1): op_2
/********** (var.) segment 3: **********
* index domain: [ iv, 3 ] -> [ _uprf_914, 4 ]
*/
(iv => _uprf_914), step0[0] 1
(0 --> 1):
(3 -> 4), step0[1] 1
(0 --> 1): op_3
/********** (var.) segment 4: **********
* index domain: [ 0, 0 ] -> [ iv, 4 ]
*/
(0 => iv), step0[0] 1
(0 --> 1):
(0 -> 4), step0[1] 1
(0 --> 1): op_4
/********** (var.) segment 5: **********
* index domain: [ _pinl_860_ub_i, 0 ] -> [ 60, 4 ]
*/
(_pinl_860_ub_i => 60), step0[0] 1
(0 --> 1):
(0 -> 4), step0[1] 1
(0 --> 1): op_4
/********** conexpr: **********/
modarray( keySpace ,RC(keySpace) ,IDX(_wlidx_1765_keySpace__SSA0_1));
However there are 4 partitions that go over iv => _uprf_914. Upon closer inspection one can see that these do not over lap as they cover different parts of the sub array 0->1, 1->2, 2->3, 3->4
These should however be done so that there is just one outer partitions and 4 inner partitions.
(iv => _uprf_914), step0[0] 1
(0 --> 1):
(0 -> 1), step0[1] 1
(0 --> 1): op_0
(1 -> 2), step0[1] 1
(0 --> 1): op_1
(2 -> 3), step0[1] 1
(0 --> 1): op_2
(3 -> 4), step0[1] 1
(0 --> 1): op_3</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1061Performance dismal in Build#16732 - WLIR failure?2017-11-19T20:19:45ZRobert BerneckyPerformance dismal in Build#16732 - WLIR failure?| | |
| --- | --- |
| Bugzilla Link | [671](http://bugs.sac-home.org/show_bug.cgi?id=671) |
| Created on | Jan 13, 2010 23:42 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Not sure what I did, ...| | |
| --- | --- |
| Bugzilla Link | [671](http://bugs.sac-home.org/show_bug.cgi?id=671) |
| Created on | Jan 13, 2010 23:42 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Not sure what I did, but use of -extrema -doawlf -nowlf is not recommended
with this build. I'll fix it on the morrow.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1060WLCSB (etc.!) interaction with extrema unfortunate2017-11-19T20:19:42ZRobert BerneckyWLCSB (etc.!) interaction with extrema unfortunate| | |
| --- | --- |
| Bugzilla Link | [668](http://bugs.sac-home.org/show_bug.cgi?id=668) |
| Created on | Jan 12, 2010 21:04 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [cblockFailAKS.sac](/uploads/4141d8f...| | |
| --- | --- |
| Bugzilla Link | [668](http://bugs.sac-home.org/show_bug.cgi?id=668) |
| Created on | Jan 12, 2010 21:04 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [cblockFailAKS.sac](/uploads/4141d8fd05751e8a3ab616e12b2a09be/cblockFailAKS.sac) |
## Extended Description
<pre>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.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1059INL fails to rename AVIS_MINVAL/AVIS_MAXVAL in crcAKD.sac2017-11-19T20:19:38ZRobert BerneckyINL fails to rename AVIS_MINVAL/AVIS_MAXVAL in crcAKD.sac| | |
| --- | --- |
| Bugzilla Link | [660](http://bugs.sac-home.org/show_bug.cgi?id=660) |
| Created on | Jan 11, 2010 22:56 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crcAKD.sac](/uploads/47547b866e2a70...| | |
| --- | --- |
| Bugzilla Link | [660](http://bugs.sac-home.org/show_bug.cgi?id=660) |
| Created on | Jan 11, 2010 22:56 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crcAKD.sac](/uploads/47547b866e2a70b1f38c578f4390ac22/crcAKD.sac) |
## Extended Description
<pre>Created an attachment (id=650)
Source code to cause crash
This in Build #16725.
cd sac/apex/crcAKD
sac2c -extrema -doawlf -nowlf -v4 crcAKD.sac -b11:saacyc:inl:3
_flat)1358, when inlined, turns to this:
_pinl_48100__flat_1358 = [ 0 ];
But this reference to it never got renamed:
int[1] _pinl_48114__ivexi_45986 { dim: 1, shape: [ 1 ], minval: _flat_1358, maxval: _wlbsc_6562_sc_bound } ;</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1058No optimization exists to weld together adjacent, identical WL partitions2017-11-19T20:19:34ZRobert BerneckyNo optimization exists to weld together adjacent, identical WL partitions| | |
| --- | --- |
| Bugzilla Link | [648](http://bugs.sac-home.org/show_bug.cgi?id=648) |
| Created on | Jan 02, 2010 14:14 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [empty2d.sac](/uploads/7598b0399a974...| | |
| --- | --- |
| Bugzilla Link | [648](http://bugs.sac-home.org/show_bug.cgi?id=648) |
| Created on | Jan 02, 2010 14:14 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [empty2d.sac](/uploads/7598b0399a9745c259990202414fce0b/empty2d.sac) |
## Extended Description
<pre>Created an attachment (id=639)
Source code to reproduce fault
(This was discussed recently in sacdev email.) If I compile
the attached, I end up with this WL:
z = with {
(_pinl_77_min_upper <= iv=[_eat_9] < _flat_2 genwidth [ _wlsimp_82 ])
{
/* empty */
} : _flat_3 ; ,
(_wlpg_45_zeros <= iv=[_eat_9] < _pinl_77_min_upper genwidth [ _isaa_102__flat_0 ])
{
/* empty */
} : _flat_3 ;
} :
There are two partitions, which have identical bodies that could be
merged into a single partition. In the more general case, the bodies
would not be identical, due to SSA and friends, but could be shown
to be functionally identical, through suitable renaming, at which time
they could be merged.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1057histlp.sac confused over WL result2017-11-19T20:19:31ZRobert Berneckyhistlp.sac confused over WL result| | |
| --- | --- |
| Bugzilla Link | [640](http://bugs.sac-home.org/show_bug.cgi?id=640) |
| Created on | Dec 27, 2009 22:06 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Applying type upgrade...| | |
| --- | --- |
| Bugzilla Link | [640](http://bugs.sac-home.org/show_bug.cgi?id=640) |
| Created on | Dec 27, 2009 22:06 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Applying type upgrade ...
ABORT: line 257 file: histlp.sac
ABORT: with loop returns 2 value(s) but 1 variable(s) specified on the lhs
This with Build #16693 (and earlier ones, so it's likely a Loch Ness introduction.
The failure occurs in CYC with
sac2c sac/apex/histlp/histlp.sac</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1056AL/DL/CF have troubles simplifying vector offsets2017-11-19T20:19:27ZRobert BerneckyAL/DL/CF have troubles simplifying vector offsets| | |
| --- | --- |
| Bugzilla Link | [636](http://bugs.sac-home.org/show_bug.cgi?id=636) |
| Created on | Dec 20, 2009 23:26 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [FngeV.sac](/uploads/e09af95b274cc4d...| | |
| --- | --- |
| Bugzilla Link | [636](http://bugs.sac-home.org/show_bug.cgi?id=636) |
| Created on | Dec 20, 2009 23:26 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [FngeV.sac](/uploads/e09af95b274cc4de75cac7c9742d2345/FngeV.sac) |
## Extended Description
<pre>Created an attachment (id=633)
Source code to reproduce fault
Not sure exactly what's going on here, but I've whittled this down
a bit. Basically, I think that AL/DL/CF can happily deal with index
vector offset computations that are scalar-based, but they aren't able to
reduce those computations when expressed as vectors. E.g.,
this will AWLF if compiled with -DFAST, but otherwise, the WL
intersection computations fail to reduce:
inline int SUM( int[.] y)
{
lim = _sub_SxS_( _sel_VxA_( [0], _shape_A_(y)), 1);
z = with {
([0] <= iv=[i] < _shape_A_(y)) {
#ifdef FAST
el = y[ [ _sub_SxS_(lim, i)] ];
#else //FAST
el = y[ _sub_SxV_(lim, iv) ];
#endif //FAST
} : el;
} : fold( +, 0);
return(z);
}
sac2c FngeV.sac v1 -b11 -doawlf -nowlf -extrema
Build #16687:MODIFIED</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1055AL/DL pessimization2017-11-19T20:19:24ZRobert BerneckyAL/DL pessimization| | |
| --- | --- |
| Bugzilla Link | [635](http://bugs.sac-home.org/show_bug.cgi?id=635) |
| Created on | Dec 20, 2009 19:26 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bugAS2.sac](/uploads/69cb4564610a1e...| | |
| --- | --- |
| Bugzilla Link | [635](http://bugs.sac-home.org/show_bug.cgi?id=635) |
| Created on | Dec 20, 2009 19:26 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bugAS2.sac](/uploads/69cb4564610a1ef87f1c09c2f7dca158/bugAS2.sac) |
## Extended Description
<pre>If I compile bugAS2.sac with "sac2c bugAS2.sac -b11", I get this in main:
_flat_0 = 5;
I = _MAIN::id( _flat_0);
_flat_1 = 23;
P = _MAIN::id( _flat_1);
_esd_63 = _neg_S_( P);
_cf_64 = _neg_S_( I);
_dl_80 = 3;
_dl_81 = _mul_SxS_( I, _dl_80);
_dl_84 = _mul_SxS_( _cf_64, _dl_80);
_dl_88 = _mul_SxS_( _esd_63, _dl_80);
_dl_105 = _mul_SxS_( P, _dl_80);
_al_1345 = _add_SxS_( _dl_105, _dl_81);
_al_1346 = _add_SxS_( _al_1345, _dl_84);
_al_1347 = _add_SxS_( _al_1346, _dl_88);
return( _al_1347);
}
which isn't exactly what we were hoping for. If I compile with
"sac2c bugAS2.sac -noal -b11", I get this:
_dl_110 = 0;
return( _dl_16687:MODIFIED110);
which is what we was hoping to see. Build #16687:MODIFIED.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1054IVE needs VP/CSE2017-11-19T20:19:21ZRobert BerneckyIVE needs VP/CSE| | |
| --- | --- |
| Bugzilla Link | [634](http://bugs.sac-home.org/show_bug.cgi?id=634) |
| Created on | Dec 20, 2009 15:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Apologies in advance ...| | |
| --- | --- |
| Bugzilla Link | [634](http://bugs.sac-home.org/show_bug.cgi?id=634) |
| Created on | Dec 20, 2009 15:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Apologies in advance for the poor nature of this entry.
I ran into this bug a while back and made a note about it,
which I then managed to recycle.
At any rate, I observed, sometime in the last several weeks,
a piece of -b11 code that looked roughly like this:
off1 = _idxs2offset_( shp, iv);
z1 = _idx_sel_( off1, X);
off2 = _idxs2offset_( shp, iv);
z2 = _idx_sel_( off2, X);
Clearly, these should be combined, somewhere before the end of phase 11,
into a single selection.
When I see this happen again, I'll append a test case to this entry.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1053DFMsetMaskOr() called with mask NULL2017-11-19T20:19:18ZDaniel RollsDFMsetMaskOr() called with mask NULL| | |
| --- | --- |
| Bugzilla Link | [626](http://bugs.sac-home.org/show_bug.cgi?id=626) |
| Created on | Dec 15, 2009 15:11 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [stripped.sac](/uploads/71163538512890...| | |
| --- | --- |
| Bugzilla Link | [626](http://bugs.sac-home.org/show_bug.cgi?id=626) |
| Created on | Dec 15, 2009 15:11 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [stripped.sac](/uploads/71163538512890d8dab497e7f53d5c23/stripped.sac), [dataflowbug.sac](/uploads/b15da789752d425e7969e0613fe79d05/dataflowbug.sac) |
## Extended Description
<pre>Created an attachment (id=628)
sac source code
development version 16678
Download the attached source code.
Run:
sac2c-d dataflowbug.sac
You'll see this:
** 15: Introducing memory management instructions ...
**** Propagating constants ...
**** AUD/SCL distinction ...
**** Making copy operations explicit ...
**** Introducing explicit allocation statements ...
**** Removing dead code ...
**** Inferring reuse candidates ...
**** Activating display of alias information ...
**** Interface aliasing analysis ...
ASSERTION FAILED: file 'tree/DataFlowMask.c', line 809
DFMsetMaskOr() called with mask NULL
EXECUTION TERMINATED</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1052TYgetScalar applied to other than array type when running type inference system2017-11-19T20:19:13ZDaniel RollsTYgetScalar applied to other than array type when running type inference system| | |
| --- | --- |
| Bugzilla Link | [625](http://bugs.sac-home.org/show_bug.cgi?id=625) |
| Created on | Dec 14, 2009 14:44 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [tvd2d_abstract.sac](/uploads/5b25d162...| | |
| --- | --- |
| Bugzilla Link | [625](http://bugs.sac-home.org/show_bug.cgi?id=625) |
| Created on | Dec 14, 2009 14:44 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [tvd2d_abstract.sac](/uploads/5b25d162093866fd5f2db7f9822e28a0/tvd2d_abstract.sac) |
## Extended Description
<pre>Created an attachment (id=627)
source code (large)
developer 16668
Goto $SACBASE/sac/demos/numerical/tvd/fluid and run make
Goto $SACBASE/sac/demos/numerical/tvd
Copy the attatched source file over tvd2d_abstract.sac
Run:
sac2c-d tvd2d_abstract.sac -L fluid -DIMUSCL=3 -v 3 -o tvd2d_abstract
** 6: Running type inference system ...
**** Enforcing Specializations ...
**** Running type inference system ...
ASSERTION FAILED: file 'typecheck/new_types.c', line 884
TYgetScalar applied to other than array type!
EXECUTION TERMINATED
The source code is attached. It's large. As usual I can reduce the size on
request but for now I just want a bug number so that this doesn't get
forgotten!</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1051N_objdef found where N_avis was expected in optimisation cycle2017-11-19T20:19:10ZDaniel RollsN_objdef found where N_avis was expected in optimisation cycle| | |
| --- | --- |
| Bugzilla Link | [624](http://bugs.sac-home.org/show_bug.cgi?id=624) |
| Created on | Dec 14, 2009 13:05 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [tvd2d_abstract.sac](/uploads/6a49a850...| | |
| --- | --- |
| Bugzilla Link | [624](http://bugs.sac-home.org/show_bug.cgi?id=624) |
| Created on | Dec 14, 2009 13:05 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [tvd2d_abstract.sac](/uploads/6a49a8503a043f894cdfde7e51c7d911/tvd2d_abstract.sac) |
## Extended Description
<pre>Created an attachment (id=626)
sac source code (large)
developer 16668
Goto $SACBASE/sac/demos/numerical/tvd/fluid and run make
Goto $SACBASE/sac/demos/numerical/tvd
Copy the attatched source file over tvd2d_abstract.sac
Run:
sac2c-d tvd2d_abstract.sac -L fluid -DIMUSCL=3 -v 3 -o tvd2d_abstract
In cycle pass 1:
TRAVERSE ERROR: node of type N_objdef found where N_avis was expected!
The source code is attached. It's large. As usual I can reduce the size on request but for now I just want a bug number so that this doesn't get forgotten!</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1050CWB introduces non-flattened code into ArrayBasics.sac2017-11-19T20:19:06ZRobert BerneckyCWB introduces non-flattened code into ArrayBasics.sac| | |
| --- | --- |
| Bugzilla Link | [620](http://bugs.sac-home.org/show_bug.cgi?id=620) |
| Created on | Dec 12, 2009 22:03 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Summary says it all. ...| | |
| --- | --- |
| Bugzilla Link | [620](http://bugs.sac-home.org/show_bug.cgi?id=620) |
| Created on | Dec 12, 2009 22:03 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Summary says it all. Build #developer rev 16671:MODIFIED linux-gnu_x86_64
(and doubtless others, too...) introduce N_num nodes into PRF_ARGs.
This caused some of my code, which naively assumed they were N_id nodes, to
break.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1049UTIndexSet.sac function inlining takes 4 minutes, 21 seconds on 1.8GHz 2-hole...2017-11-19T20:19:03ZRobert BerneckyUTIndexSet.sac function inlining takes 4 minutes, 21 seconds on 1.8GHz 2-holer Opteron| | |
| --- | --- |
| Bugzilla Link | [612](http://bugs.sac-home.org/show_bug.cgi?id=612) |
| Created on | Nov 27, 2009 15:03 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTIndexSet.sac](/uploads/59e4d7d16d...| | |
| --- | --- |
| Bugzilla Link | [612](http://bugs.sac-home.org/show_bug.cgi?id=612) |
| Created on | Nov 27, 2009 15:03 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTIndexSet.sac](/uploads/59e4d7d16d61cd19281387aa10f7df79/UTIndexSet.sac), [UTThornBoolean.sac](/uploads/17c326b57111db9c7fc7ea0aed6d87e3/UTThornBoolean.sac), [crud.sac](/uploads/3eec18b85236f9fced2bc9c922394939/crud.sac) |
## Extended Description
<pre>Created an attachment (id=616)
Source code to reproduce fault
Build #developer rev 16638. Summary says it all.
This amount of time to copy some code
seems a trifle excessive.
Otherwise, no problem.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1047Someone (WLF?) still propagates constants into WL generator bounds2017-11-19T20:18:55ZRobert BerneckySomeone (WLF?) still propagates constants into WL generator bounds| | |
| --- | --- |
| Bugzilla Link | [609](http://bugs.sac-home.org/show_bug.cgi?id=609) |
| Created on | Nov 26, 2009 22:30 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>sac2c slice.sac -b11
...| | |
| --- | --- |
| Bugzilla Link | [609](http://bugs.sac-home.org/show_bug.cgi?id=609) |
| Created on | Nov 26, 2009 22:30 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>sac2c slice.sac -b11
where slice.sac is:
use Array: all;
int main()
{
shp = [25];
ylo = [5];
yhi = [25];
xlo = ylo - [8];
xhi = yhi + [20];
z = with {
( xlo <= iv <= xhi) : _sel_VxA_( [0], iv);
( ylo <= iv <= yhi) : _sel_VxA_( [0], iv);
} : genarray ( shp, 42);
StdIO::print(z);
return(0);
}
produces:
z = with {
([ 5 ] <= iv__SSA0_1=[_eat_23] < [ 26 ] genwidth [ _wlsimp_627 ])
{
/* empty */
} : _eat_23 ; ,
([ 0 ] <= iv__SSA0_1=[_eat_23] < [ 5 ] genwidth [ _wlsimp_626 ])
{
/* empty */
} : _eat_23 ;
} :
genarray( [ 25 ]);
I'm guessing WLF because if I compile with -nowlf, we get N_id nodes in
the generator bounds.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1046Odd behavior of and()2017-11-19T20:18:52ZRobert BerneckyOdd behavior of and()| | |
| --- | --- |
| Bugzilla Link | [592](http://bugs.sac-home.org/show_bug.cgi?id=592) |
| Created on | Nov 13, 2009 22:09 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I was looking at...| | |
| --- | --- |
| Bugzilla Link | [592](http://bugs.sac-home.org/show_bug.cgi?id=592) |
| Created on | Nov 13, 2009 22:09 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I was looking at match() code, and noted that it uses
fold. At that point, I began to wonder if foldfix was
working not working, or integrated into fold.
So, I wrote this here function:
use Array:all;
use StdIO:{print};
int main()
{
b = genarray([200000000], true);
z = any (b);
print(z);
return(0);
}
It generates this WL:
_pinl_225_res = with {
([ 0 ] <= _pinl_223_iv=[_pinl_226__eat_12] < [ 200000000 ])
{
_pinl_227__ea_165_res = _accu_( _pinl_223_iv);
_pinl_233__217__flat_13 = _or_SxS_( _pinl_227__ea_165_res, _flat_1);
} : _pinl_233__217__flat_13 ;
} :
fold( ScalarArith::|, _pinl_222__flat_6);
From what I can tell, that the fold WL does not quick-stop, suggesting
that foldfix is broken, non-existent, or something else.
However, more interesting is the slight variant on the above, when you change
the "true" to false. Then, it generates this:
_pinl_225_res = false;
This suggested to me that the typechecker might be detecting
one possible reduction identity case, but not the other.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1045Weird with-loops2017-11-19T20:18:49ZRobert BerneckyWeird with-loops| | |
| --- | --- |
| Bugzilla Link | [589](http://bugs.sac-home.org/show_bug.cgi?id=589) |
| Created on | Nov 11, 2009 17:02 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud2.sac](/uploads/d9d5750d11...| | |
| --- | --- |
| Bugzilla Link | [589](http://bugs.sac-home.org/show_bug.cgi?id=589) |
| Created on | Nov 11, 2009 17:02 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud2.sac](/uploads/d9d5750d11355dbf267059c5830bbd8d/crud2.sac) |
## Extended Description
<pre>Created an attachment (id=596)
Source code to reproduce fault
The attached (unlikely) code exhibits several interesting properties.
When compiled with Build #16534 (and probably many earlier ones...),
sac2c -b11 crud2.sac
produces this function:
-----------------------------------------------------
_pinl_622__flat_792 = true;
_pinl_624_res__SSA0_1 = with {
([ 0 ] <= _pinl_623_iv__SSA0_1=[_pinl_626__eat_11] (IDXS:_wlidx_1240__pinl_624_res__SSA0_1) < [ 8 ])
{
/* empty */
} : _pinl_622__flat_792 ; ,
([ 8 ] <= _pinl_623_iv__SSA0_1=[_pinl_626__eat_11] (IDXS:_wlidx_1240__pinl_624_res__SSA0_1) < [ 16 ])
{
/* empty */
} : _pinl_622__flat_792 ;
} :
genarray( [ 16 ], IDX(_wlidx_1240__pinl_624_res__SSA0_1));
----------------------------------------------------------------
I am not sure if this gets merged back into a single WL in the back end
or not. However, it does look weird.
Even weirder is what we get when compiled with:
sac2c -b11 -extrema -doawlf -nowlf crud2.sac
------------------------------------------------------
_pinl_612_res = with {
(_flatg_982 <= _pinl_610_iv=[_pinl_625__eat_10] (IDXS:_wlidx_1375__pinl_612_res) < _flatg_980)
{
/* empty */
} : _pinl_611__flat_784 ; ,
(_flatg_980 <= _pinl_610_iv=[_pinl_625__eat_10] (IDXS:_wlidx_1375__pinl_612_res) < _flatg_981)
{
/* empty */
} : _pinl_513__flat_780 ;
} :
genarray( [ 16 ], _pinl_513__flat_780, IDX(_wlidx_1375__pinl_612_res));
_pinl_624_res__SSA0_1__SSA4_1 = _idx_modarray_AxSxS_( _pinl_612_res, _pinl_598__flat_777, _pinl_611__flat_784);
_ivesplit_1382 = 9;
_pinl_624_res__SSA0_1__SSA4_2 = _idx_modarray_AxSxS_( _pinl_624_res__SSA0_1__SSA4_1, _ivesplit_1382, _pinl_611__flat_784);
_ivesplit_1383 = 10;
_pinl_624_res__SSA0_1__SSA4_3 = _idx_modarray_AxSxS_( _pinl_624_res__SSA0_1__SSA4_2, _ivesplit_1383, _pinl_611__flat_784);
_ivesplit_1384 = 11;
_pinl_624_res__SSA0_1__SSA4_4 = _idx_modarray_AxSxS_( _pinl_624_res__SSA0_1__SSA4_3, _ivesplit_1384, _pinl_611__flat_784);
_ivesplit_1385 = 12;
_pinl_624_res__SSA0_1__SSA4_5 = _idx_modarray_AxSxS_( _pinl_624_res__SSA0_1__SSA4_4, _ivesplit_1385, _pinl_611__flat_784);
_ivesplit_1386 = 13;
_pinl_624_res__SSA0_1__SSA4_6 = _idx_modarray_AxSxS_( _pinl_624_res__SSA0_1__SSA4_5, _ivesplit_1386, _pinl_611__flat_784);
_ivesplit_1387 = 14;
_pinl_624_res__SSA0_1__SSA4_7 = _idx_modarray_AxSxS_( _pinl_624_res__SSA0_1__SSA4_6, _ivesplit_1387, _pinl_611__flat_784);
_ivesplit_1388 = 15;
_pinl_624_res__SSA0_1__SSA4_8 = _idx_modarray_AxSxS_( _pinl_624_res__SSA0_1__SSA4_7, _ivesplit_1388, _pinl_611__flat_784);
return( _pinl_624_res__SSA0_1__SSA4_8);
}
-----------------------------------
Doesn't look very healthy from a performance viewpoint.
I'm not going to be able to look into it right away, but
wanted to note the problem, while it's fresh in my mind.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1044AES tries to read freed memory2017-11-19T20:18:46ZCarl JoslinAES tries to read freed memory| | |
| --- | --- |
| Bugzilla Link | [573](http://bugs.sac-home.org/show_bug.cgi?id=573) |
| Created on | Oct 16, 2009 14:12 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [xaes.sac](/uploads/c1e7893e05c...| | |
| --- | --- |
| Bugzilla Link | [573](http://bugs.sac-home.org/show_bug.cgi?id=573) |
| Created on | Oct 16, 2009 14:12 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [xaes.sac](/uploads/c1e7893e05c5a2a6f362c52ef4777b22/xaes.sac), [aes.sac](/uploads/be83614bc9e9766f67a400586db52ce7/aes.sac) |
## Extended Description
<pre>AES tries to read memory at runtime where the memories reference count has reached 0. This is at the end of for loop (do/while).
sac2c v1.00-beta (Buchette d'Anjou)
developer rev 16478 linux-gnu_i686
(Fri Oct 16 12:16:56 BST 2009 by caj)
sac2c -target sl -DITERATE -DSACSL aes.sac</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1043CFfuncond can't handle matching legs2017-11-19T20:18:42ZRobert BerneckyCFfuncond can't handle matching legs| | |
| --- | --- |
| Bugzilla Link | [526](http://bugs.sac-home.org/show_bug.cgi?id=526) |
| Created on | Jul 16, 2009 22:45 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [iotaonly8.sac](/uploads/1527ca...| | |
| --- | --- |
| Bugzilla Link | [526](http://bugs.sac-home.org/show_bug.cgi?id=526) |
| Created on | Jul 16, 2009 22:45 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [iotaonly8.sac](/uploads/1527cae5c5a342495efb390ced8f66ac/iotaonly8.sac) |
## Extended Description
I was dusting off the constant folder today, and noted that CFfuncond
doesn't catch the case of:
z5 = id(true) ? t1 : t1;
The problem is that. by the time CF looks at the expression, it is a lacfn,
so t1 and t1 have become t1 and t2, and they will never match.BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1041Loop fn contains superfluous parameters, causing 2.5X slowdown2017-11-19T20:18:35ZRobert BerneckyLoop fn contains superfluous parameters, causing 2.5X slowdown| | |
| --- | --- |
| Bugzilla Link | [512](http://bugs.sac-home.org/show_bug.cgi?id=512) |
| Created on | Jun 19, 2009 16:38 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This is a care o...| | |
| --- | --- |
| Bugzilla Link | [512](http://bugs.sac-home.org/show_bug.cgi?id=512) |
| Created on | Jun 19, 2009 16:38 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This is a care of the APEX apex/testlcv/testlcv.sac versus the
apex/testlcvAKD/testlcvAKD.sac benchmarks. Here is the inner loop code
for both of them; the only difference is whether n is statically known:
inline double testlcvXID(int n)
{
r_0=tod(( false));
j_0=( 9);
A_40=iota( n);
A_CTR41_= 0;
A_CTR41z_ = (shape(A_40)[[0]])-1;
r_2=tod(r_0);
j_2=tod(j_0);
for(; A_CTR41_ <= A_CTR41z_; A_CTR41_++){
i_0 = A_40[[A_CTR41_]];
A_44=r_2, + i_0;
r_2=( A_44);
A_46=r_2 + 1.0;
j_2=( A_46);
}
A_49=r_2 + j_2;
r_3=( A_49);
return(r_3);
}
In the AKD version, we find this function:
* Loop function:
* _MAIN::_dup_659__testlcvXID__Loop_0(...)
****************************************************************************/
#3194: in [ double, double] le < 3203> ge < 3205>, #3195: in [ double, double] le < 3204> ge < 3206> _MAIN::_dup_659__testlcvXID__Loop_0( #3189: in [ int[1], int[1]] le <> ge <> _isaa_2231_A_40 { dim: 1, shape: [ 1 ] } , #3190: in [ int[.], int[.]] le <> ge <> A_40 { dim: 1, shape: _isaa_2231_A_40 } , #3191: in [ int, int] le <> ge <> A_CTR41_ { dim: 0, shape: [:int] } , #3192: in [ int, int] le <> ge <> A_CTR41z_ { dim: 0, shape: [:int] } , #3193: in [ double, double] le <> ge <> r_2 { dim: 0, shape: [:int] } )
...
_cf_2498_A_40 = _idx_shape_sel_( 0, A_40);
_cf_2499 = [ _cf_2498_A_40 ];
if (_pinl_2014__flat_41)
{
_lirmov_711_A_46, r_2__SSA0_2 = _MAIN::_dup_659__testlcvXID__Loop_0( _cf_2499, A_40, _pinl_2013__flat_69, A_CTR41z_, _pinl_2006___flat_53);
The only notable differences in the two codes is the _cf_2499 set,
the _cf_2498_A_40 set, and the fact that _cf_2499 is passed into each
call, even though it is never explicitly referenced.
I am guessing that the SAA code is generating the extra parameter, but it would be nice if we could get rid of it in cases like this.</pre>BugZillaBugZilla