sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T20:21:21Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1086tomcatv2 dies in memory management generation and in tup2017-11-19T20:21:21ZRobert Berneckytomcatv2 dies in memory management generation and in tup| | |
| --- | --- |
| Bugzilla Link | [779](http://bugs.sac-home.org/show_bug.cgi?id=779) |
| Created on | Nov 20, 2010 13:27 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [tomcatv2.sac](/uploads/8152a2227c04...| | |
| --- | --- |
| Bugzilla Link | [779](http://bugs.sac-home.org/show_bug.cgi?id=779) |
| Created on | Nov 20, 2010 13:27 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [tomcatv2.sac](/uploads/8152a2227c04b0aa803c6c3e5eeb490b/tomcatv2.sac) |
## Extended Description
<pre>Created an attachment (id=773)
source code to reproduce fault
sac2c apex/tomcatv2/tomcatv2.sac -noopt -O3
** 16: Introducing memory management instructions ...
**** AUD/SCL distinction ...
-----------------------------------------------
It also dies this way:
sac2c tomcatv2.sac -O3 -v4
OOOOOOOPS, your program crashed the compiler 8-((
**** Optimization cycle pass: 5
****** Optimizing regular function:
****** _MAIN::main( hidden(1), hidden(2), hidden(0)): ...
Applying common subexpression elimination ...
Inferring loop invariant variables ...
Applying type upgrade ...
ABORT: line 491 file: tomcatv2.sac
ABORT: with loop returns 3 value(s) but 1 variable(s) specified on the lhs
*** Compilation failed ***
*** Exit code 87 (Running SAC optimizations)
*** 1 Error(s), 34 Warning(s)
sac@rattler:~/sac/apex/tomcatv2$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
product rev 17200:MODIFIED linux-gnu_x86_64
(Fri Nov 19 17:52:54 EST 2010 by sac)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1085CF fails to kill modarray in constantfolding/SCCFprf_modarray5.sac2017-11-19T20:21:18ZRobert BerneckyCF fails to kill modarray in constantfolding/SCCFprf_modarray5.sac| | |
| --- | --- |
| Bugzilla Link | [778](http://bugs.sac-home.org/show_bug.cgi?id=778) |
| Created on | Nov 19, 2010 19:57 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>If the above unit tes...| | |
| --- | --- |
| Bugzilla Link | [778](http://bugs.sac-home.org/show_bug.cgi?id=778) |
| Created on | Nov 19, 2010 19:57 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>If the above unit test is compiled with:
-maxwlur 1 -docf -extrema -nowlf -doawlf -ecc
the modarray() call in tghe code is left there. Although CF properly
eliminates the modarray() from the result-using part of the code,
we are left with guards that refer to the modarray result, in order
to get its shape:
_flat_1 = true;
_flat_0 = 1;
one = _MAIN::id( _flat_0, _flat_1) ;
_isaa_49_one = _dim_A_( one);
_isaa_50_one = _shape_A_( one);
_isaa_51_one = _saabind_( _isaa_49_one, _isaa_50_one, one);
_idc_38, _icc_27_pred = _type_constraint_( int, _isaa_51_one);
_icc_28 = _add_SxS_( _idc_38, _flat_0);
_flat_2 = _afterguard_( _icc_28, _icc_27_pred);
cltwo = _MAIN::id( _flat_2, _flat_1) ;
_isaa_52_cltwo = _dim_A_( cltwo);
_isaa_53_cltwo = _shape_A_( cltwo);
_isaa_54_cltwo = _saabind_( _isaa_52_cltwo, _isaa_53_cltwo, cltwo);
_flat_5 = 5;
five = _MAIN::id( _flat_5, _flat_1) ;
_isaa_55_five = _dim_A_( five);
_isaa_56_five = _shape_A_( five);
_isaa_57_five = _saabind_( _isaa_55_five, _isaa_56_five, five);
_idc_39, _icc_29_pred = _type_constraint_( int, _isaa_57_five);
_flat_7 = [:int];
_idc_40, _icc_30_pred = _shape_matches_dim_VxA_( _flat_7, _isaa_54_cltwo);
_idc_42, _icc_32_pred = _val_lt_shape_VxA_( _flat_7, _isaa_54_cltwo);
_icc_33 = _modarray_AxVxS_( _isaa_54_cltwo, _flat_7, _idc_39);
x3 = _afterguard_( _icc_33, _icc_32_pred, _icc_30_pred, _icc_29_pred);
_idc_44, _icc_34_pred = _shape_matches_dim_VxA_( _flat_7, x3);
_idc_45, _icc_36_pred = _val_lt_shape_VxA_( _idc_44, x3);
z = _afterguard_( _idc_39, _icc_36_pred, _icc_34_pred);
_esd_48 = -5;
z__SSA0_1 = _add_SxS_( z, _esd_48);
return( z__SSA0_1);
I think the best approach here is to replace guards that refer to
dim or shape by new guards that use _shape_A_ or _dim_A_.
Other CF code would then replace those by the SAA shape/dim
of the array.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1084Masterrun failures2017-11-19T20:21:15ZDaniel RollsMasterrun failures| | |
| --- | --- |
| Bugzilla Link | [777](http://bugs.sac-home.org/show_bug.cgi?id=777) |
| Created on | Nov 19, 2010 11:24 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
This is a tracker bug to mon...| | |
| --- | --- |
| Bugzilla Link | [777](http://bugs.sac-home.org/show_bug.cgi?id=777) |
| Created on | Nov 19, 2010 11:24 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
This is a tracker bug to monitor those bugs which cause sac2c, stdlib or testcases to fail or produce wrong results in a masterrun. This bug is for failures only, not warnings.BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1083APEX masterrun failures2017-11-19T20:21:12ZRobert BerneckyAPEX masterrun failures| | |
| --- | --- |
| Bugzilla Link | [774](http://bugs.sac-home.org/show_bug.cgi?id=774) |
| Created on | Nov 16, 2010 20:33 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This is a summary of ...| | |
| --- | --- |
| Bugzilla Link | [774](http://bugs.sac-home.org/show_bug.cgi?id=774) |
| Created on | Nov 16, 2010 20:33 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This is a summary of masterrun failure modes for APEX benchmarks, as of 2010-11-16.
In the "runs forever, or close to it" category, we have crc*, ipape*
ipplusand*, ipopne*, ulam*, UTReduce,
---------------------------
OOOOOOOPS, your program crashed the compiler 8-((
OOOOOOOPS, your program crashed the compiler 8-((
OOOOOOOPS, your program crashed the compiler 8-((
OOOOOOOPS, your program crashed the compiler 8-((
Not much of clue here. Perhaps sac2c should give some more hints as
to what program was running?
--------------------------------
ERROR: unknown user defined type `_MAIN::time'.
ERROR: unknown user defined type `_MAIN::time'.
ERROR: unknown user defined type `_MAIN::time'.
ERROR: unknown user defined type `_MAIN::time'.
This reflects an undocumented (as far as I can tell) change to
stdlib contents.
UTClock suffers from a related problem.
--------------------------
make[6]: [dtb] Error 87 (ignored)
make[6]: [dtb_mt] Error 87 (ignored)
make[6]: [dtb2] Error 87 (ignored)
make[6]: [dtb2_mt] Error 87 (ignored)
These are WLF failures. See Bug# 773 and perhaps others.
Caused by subtraction in an index vector.
UTReverse suffers from same bug.
UTRotate234.sac ditto.
ABORT: line 290 file: ArrayBasics.sac
ABORT: Array access to _pinl_9586_z out of range in dimension 1
-----------------------------------------
make[6]: *** [.ipapeijk.d] Error 1
This is a hand-coded variant of the ipape inner product benchmark.
It needs fixing.
Or, perhaps, as the hillbilly murder defense was put: He needed killin'.
Fixed in sac/apex/ipape build #1316.
-----------------------------------------
logd*, mconv*, metaph*, nmo* failures: APEX compiler problems.
----------------------------------------
mdiv*: sac2c crashes. Cause not investigated.
-----------------------------------------------
UTEpio, rle3AKD: excessive compile time.
-----------------------------------------------
UTThornInt: excessive compile time.
-------------------------------------
UTThornReal: perhaps sac2c problem introduced when
new integer types arrived. I crippled it, because it
took forever to compile.
--------------------------------------
In general, things are, despite how this looks, improving!</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1082dtb* failures in WLF2017-11-19T20:21:09ZRobert Berneckydtb* failures in WLF| | |
| --- | --- |
| Bugzilla Link | [773](http://bugs.sac-home.org/show_bug.cgi?id=773) |
| Created on | Nov 16, 2010 19:52 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
sac/apex/dtb/dtb.sac and f...| | |
| --- | --- |
| Bugzilla Link | [773](http://bugs.sac-home.org/show_bug.cgi?id=773) |
| Created on | Nov 16, 2010 19:52 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
sac/apex/dtb/dtb.sac and friends all fail in WLF due to subtractions
in index vectors operating in a consumerWL on data from a producerWL.
I thought we had a bugzilla entry for this, but none are showing
up, so here go again. This one goes WAY back.BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1081LUR can not handle Compare to zero2017-11-19T20:21:06ZCarl JoslinLUR can not handle Compare to zero| | |
| --- | --- |
| Bugzilla Link | [772](http://bugs.sac-home.org/show_bug.cgi?id=772) |
| Created on | Nov 09, 2010 15:16 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
Loop unrolling can not mat...| | |
| --- | --- |
| Bugzilla Link | [772](http://bugs.sac-home.org/show_bug.cgi?id=772) |
| Created on | Nov 09, 2010 15:16 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
Loop unrolling can not match the code patten that is produced when compare to zero.
More details to follow.BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1080Dimension of array lost?2017-11-19T20:21:02ZCarl JoslinDimension of array lost?| | |
| --- | --- |
| Bugzilla Link | [762](http://bugs.sac-home.org/show_bug.cgi?id=762) |
| Created on | Oct 19, 2010 14:00 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [loop8p.sac](/uploads/608c9a8c030125...| | |
| --- | --- |
| Bugzilla Link | [762](http://bugs.sac-home.org/show_bug.cgi?id=762) |
| Created on | Oct 19, 2010 14:00 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [loop8p.sac](/uploads/608c9a8c030125fa9c67485b6dde5e53/loop8p.sac), [loop8.inp](/uploads/91af819caff05e8de577ed50640c5d3a/loop8.inp) |
## Extended Description
<pre>When running loop8 with icc the following error is produced
*** SAC runtime error
*** No appropriate instance of function "_MAIN::Loop8 :: int[*] int[*] double[*] double[*] double[*] double[*] double[*] -> double[.,.,.] " found!
*** Shape of arguments:
*** [ 1]
*** []
*** [ 5, 2, 101]
*** [ 5, 2, 101]
*** [ 5, 2, 101]
*** [ 5, 2, 101]
*** [ 10, 13, 3, 1010, 5, 2, 101, 4209518, 0, 25415280, 0, 1125511200, 32767, 25407152, 0, 1125511168, 32767, 1125511152, 32767, 500001, 1, 25445888, 0, 1125511136, 32767, 100, 32632, 25407248, 0, 25407280, 0, 500001, 1, 24747728, 0, 24866928, 0, 100, 0...]
To me it appears that the dimensionality of the last argument to _MAIN::Loop8 has been lost/uninitialized. However from the source code this argument should be AKS, double[10]
This does not seem to happen for gcc which makes this quite strange.
Detail of how to reproduce will be added by dsr</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1079-ecc makes AWLF ineffective for cubeslice1dbeta.sac2017-11-19T20:20:58ZRobert Bernecky-ecc makes AWLF ineffective for cubeslice1dbeta.sac| | |
| --- | --- |
| Bugzilla Link | [761](http://bugs.sac-home.org/show_bug.cgi?id=761) |
| Created on | Oct 16, 2010 14:27 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud](/uploads/5588efbe6b5037d2c0e4...| | |
| --- | --- |
| Bugzilla Link | [761](http://bugs.sac-home.org/show_bug.cgi?id=761) |
| Created on | Oct 16, 2010 14:27 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud](/uploads/5588efbe6b5037d2c0e488eacd03ee88/crud), [cubeslice1dbeta.sac](/uploads/1fadd3388841f6975915d9d259159bc8/cubeslice1dbeta.sac) |
## Extended Description
<pre>Created an attachment (id=764)
Output from sac2c cubeslice1dbeta.sac -ecc -extrema -nowlf -dowlf -bopt:uglf
The attachment is from:
sac2c cubeslice1dbeta.sac -ecc -extrema -nowlf -dowlf -bopt:uglf</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1078scc constraint removal can produce empty WL block!2017-11-19T20:20:54ZRobert Berneckyscc constraint removal can produce empty WL block!| | |
| --- | --- |
| Bugzilla Link | [756](http://bugs.sac-home.org/show_bug.cgi?id=756) |
| Created on | Oct 03, 2010 21:45 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/94c77dc95aea2196...| | |
| --- | --- |
| Bugzilla Link | [756](http://bugs.sac-home.org/show_bug.cgi?id=756) |
| Created on | Oct 03, 2010 21:45 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/94c77dc95aea21967a33d34fcf6cad63/crud.sac) |
## Extended Description
<pre>In the attached, compiling with:
sac2c-d crud.sac -O3 -doawlf -nowlf -extrema -ecc -v1
for build #developer rev 17069:MODIFIED
causes a crash in EBT after SCC. It looks like the problem
is that SCC blindly eliminates code from a block, but
this can (and does, in this case) result it removing the
last piece of code from an N_with code block, which is
verboten.
I think the fix is to put some code in SCCblock to check
for this and insert the canonical EMPTY marker if the
block does become empty.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1077First axis reduction of tensor runs 10X slower than reduction of entire tensor2017-11-19T20:20:50ZRobert BerneckyFirst axis reduction of tensor runs 10X slower than reduction of entire tensor| | |
| --- | --- |
| Bugzilla Link | [754](http://bugs.sac-home.org/show_bug.cgi?id=754) |
| Created on | Sep 30, 2010 19:46 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/7129bd81622fc598...| | |
| --- | --- |
| Bugzilla Link | [754](http://bugs.sac-home.org/show_bug.cgi?id=754) |
| Created on | Sep 30, 2010 19:46 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/7129bd81622fc5989704708be7bdf606/crud.sac) |
## Extended Description
<pre>Created an attachment (id=758)
source code to reproduce fault
The attached code performs a sum reduction over the first axis of
a rank-3 array, if compiled with:
sac2c -O3 crud.sac -DSLOW
The resulting code executes in roughly 7 seconds on a 3GHz Opteron.
If I have the Ubuntu system monitor running, I see that memory usage
creeps up DURING the execution of the reduction. This is surprising,
as I would naively expect that all allocations would be done before
we enter the loop.
If compiled with:
sac2c -O3 crud.sac
The resulting code performs a sum() over the entire tensor, and executes in
about 0.85 seconds.
The offending function is likely this one:
inline int[+] plussl1XBIFOLD(bool[+] y)
{ /* first-axis reduce rank-3 or greater matrix */
yt = transpose(y);
zrho = drop([-1], shape(yt));
z = with {
(. <= iv <= .)
: sum(toi((yt[iv])));
} : genarray(zrho, 0);
return(z);
}
Perhaps there is a better way to express such a reduction?
The idea here is that an argument of shape [ 10,20,30] will
give a result shape of [20,30].
Part of the problem is that the reduction array shape is AKD,
which is causing some WLF opportunities to be missed.
However, declaring the reduce argument this way:
bool[3000, 15000,3] A_23;
still leaves the -DSLOW code running about 6X slower than
the other code.
This on: product rev 17069:MODIFIED linux-gnu_x86_64</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1076modarray causes LIR failure2017-11-19T20:20:46ZRobert Berneckymodarray causes LIR failure| | |
| --- | --- |
| Bugzilla Link | [750](http://bugs.sac-home.org/show_bug.cgi?id=750) |
| Created on | Sep 26, 2010 17:48 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.reallyslow.sac](/uploads/4676d...| | |
| --- | --- |
| Bugzilla Link | [750](http://bugs.sac-home.org/show_bug.cgi?id=750) |
| Created on | Sep 26, 2010 17:48 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.reallyslow.sac](/uploads/4676d7b3e8db97b994da7456c0b66fb9/crud.reallyslow.sac) |
## Extended Description
<pre>Created an attachment (id=757)
source code to reproduce fault
The attached SAC code, if compiled with -DGOSLOW, ends up recomputing
the Boolean vector on every iteration through the indexof (iotaBBI) loop.
This is A Bad Thing, if you have any interest in (good) performance.
I just came across thie by accident, while lamenting the compiler's
inability to fold a WL into a FOR-loop.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1075Numerical constants printed without qualifier2017-11-19T20:20:42ZClemens GrelckNumerical constants printed without qualifier| | |
| --- | --- |
| Bugzilla Link | [715](http://bugs.sac-home.org/show_bug.cgi?id=715) |
| Created on | May 28, 2010 08:45 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Numerical constants o...| | |
| --- | --- |
| Bugzilla Link | [715](http://bugs.sac-home.org/show_bug.cgi?id=715) |
| Created on | May 28, 2010 08:45 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Numerical constants of the new built-in types short/long/unsigned/etc
are printed without the agree character extension. That makes them difficult
to distinguish from standard int constants and is incompatible to the
parser.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1074ipbdAKD.sac peformance problems w/ AWLF, extrema2017-11-19T20:20:39ZRobert BerneckyipbdAKD.sac peformance problems w/ AWLF, extrema| | |
| --- | --- |
| Bugzilla Link | [710](http://bugs.sac-home.org/show_bug.cgi?id=710) |
| Created on | May 14, 2010 14:11 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/288e6db606a55863...| | |
| --- | --- |
| Bugzilla Link | [710](http://bugs.sac-home.org/show_bug.cgi?id=710) |
| Created on | May 14, 2010 14:11 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/288e6db606a55863dceebcb964947815/crud.sac), [xcrud.sac](/uploads/95f6705d751325e2d8b226b1d5bf577b/xcrud.sac), [crud.ecclir.gz](/uploads/78cd2711a3c4f51c09277f897ef46dbc/crud.ecclir.gz) |
## Extended Description
<pre>Created an attachment (id=712)
source code to reproduce fault
Recent code changes on rattler, either due to my AWLF/extrema work, the WLBSC
changes of yesterday, other repository changes, or some combination thereof,
have clobbered the performance of some APEX benchmarks. The Boolean-double
matrix product ipbdAKD is typical of these.
The Loop_1 function contains this unpleasantness:
_ivesplit_16330 = 0;
_ivesplit_16331 = 1;
_ = with {
([ 0 ] <= _pinl_9242_iv=[_eat_11993] (IDXS:_wlidx_16309__pinl_9233__icc_4507) < [ _uprf_12172 ])
{
_pinl_9243_new_idx = _cat_VxV_( row, _pinl_9242_iv);
_uprf_12161 = _idx_sel_( _ivesplit_16330, _pinl_9243_new_idx);
_uprf_12166 = _idx_sel_( _ivesplit_16331, _pinl_9243_new_idx);
_ivesplit_16332 = _idxs2offset_( _isaa_12791_x, _uprf_12161, _uprf_12166);
_pinl_9232__icc_4505 = _idx_sel_( _ivesplit_16332, x);
} : _pinl_9232__icc_4505 ;
} :
genarray( [ _uprf_12172 ], _pinl_9241__flat_68, IDX(_wlidx_16309__pinl_9233__icc_4507));
_ivesplit_16333 = colx;
_pinl_9276__icc_3294 = _idx_sel_( _ivesplit_16333, _pinl_9233__icc_4507);
Note that:
1. _pinl_9233__icc_4507 is copying a row from x.
2. The following reference to that result selects a single element from
that row.
I'll try to come up a short example of this, but the code base
exists only on rattler at this juncture, so you won't easily be able to
try it.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/10734.79X post-Loch Ness performance loss in histlp.sac2017-11-19T20:20:34ZRobert Bernecky4.79X post-Loch Ness performance loss in histlp.sac| | |
| --- | --- |
| Bugzilla Link | [709](http://bugs.sac-home.org/show_bug.cgi?id=709) |
| Created on | May 13, 2010 20:20 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/db69aa9ad2a097ab...| | |
| --- | --- |
| Bugzilla Link | [709](http://bugs.sac-home.org/show_bug.cgi?id=709) |
| Created on | May 13, 2010 20:20 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/db69aa9ad2a097ab48f3cfb2b9dd668e/crud.sac), [crud.b11](/uploads/f4213fcb925dab91a86458034d8886f1/crud.b11), [crud.prelochness](/uploads/f86d4eddbb1511444df856db7285aefe/crud.prelochness), [xcrud.prelochness](/uploads/6c80201793b29dc48abd37ecd7f3d7c1/xcrud.prelochness) |
## Extended Description
<pre>Created an attachment (id=710)
Dan's pre-Loch Ness -b13 output
This is the most egregious of the remaining performance loss problems
introduced at Loch Ness. apex/histlp/histlp.sac now executes about 5X slower
than pre-Loch Ness.
The Loop_0 functions before and after look nearly identical, except for
these two lines:
_pinl_3552__wlbsc_2356_sc_e = _idx_sel_( _ivesplit_5497, _isaa_4840_r_2);
_pinl_3553__wlbsc_2357_sc_bound = [ _pinl_3552__wlbsc_2356_sc_e ];
ivesplit_5497 is 0, but the Loop_0 function header doesn't see that; it
sees it as an AKS int.
Similarly, _isaa_4840_r_2 is a parameter, but it is int[1], and
_pinl_3553__wlbsc_2357_sc_bound becomes that parameter in the recursive call.
So, the two lines are, effectively, a no-op.
The picture is made a bit murkier by the fact that
_pinl_3553__wlbsc_2357_sc_bound is also one of the results of
Loop_0.
I can see how LIR might have trouble pulling these lines out of the loop
function. If we can't fancy up LIR enough to do the job, perhaps we
can do an UNWLBSC traversal somewhere around the end of Phase 11.
This, however, would not work in the current code, because _ivesplit_5497
is not AKV.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1072Performance anomaly in Livermore Loops when declarations are used2017-11-19T20:20:27ZRobert BerneckyPerformance anomaly in Livermore Loops when declarations are used| | |
| --- | --- |
| Bugzilla Link | [707](http://bugs.sac-home.org/show_bug.cgi?id=707) |
| Created on | May 11, 2010 18:13 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I've been running per...| | |
| --- | --- |
| Bugzilla Link | [707](http://bugs.sac-home.org/show_bug.cgi?id=707) |
| Created on | May 11, 2010 18:13 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I've been running performance measurements of the Livermore Loops in sac.
When I compiled loop10.sac, I got a gazillion complaints about:
WARNING: Insufficient symbolic shape information available. Using explicit
WARNING: information to split index operation.
Looking at the code, we see in main():
rep = FibreScanInt( stdin );
n = FibreScanInt( stdin );
I looked at n and rep, and noted that they are not declared,
but are passed to the Loop() function, where they are NOT referenced or set.
In the spirit of cleaning things up, I tried some simple tests:
(This is op counts, compiling with AWLF options on rbe's private code.)
Original:
6715137927
n and rep removed from Loop() call:
7905664809 !! WORSE !!
n and rep removed from Loop() call; "int rep; int n;" added to main():
7850187292 slightly better
When compiled with -O3...
Original:
loop10.sac.exe.O3.16831:MODIFIED.papiex.rattler.18553:PAPI_TOT_INS: 965058436
n and rep removed from Loop() call:
loop10.sac.exe.O3.16831:MODIFIED.papiex.rattler.18633:PAPI_TOT_INS: 947804966
n and rep removed from Loop() call; "int rep; int n;" added to main():
loop10.sac.exe.O3.16831:MODIFIED.papiex.rattler.18753:PAPI_TOT_INS: 934451791
I do not understand what's going on here.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1071SelModArray() in CF broken when using -ecc/ -check c (SCCFprf_modarray11.sac)2017-11-19T20:20:24ZRobert BerneckySelModArray() in CF broken when using -ecc/ -check c (SCCFprf_modarray11.sac)| | |
| --- | --- |
| Bugzilla Link | [701](http://bugs.sac-home.org/show_bug.cgi?id=701) |
| Created on | Apr 26, 2010 16:49 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [SCCFprf_modarray11.sac](/uploads/94...| | |
| --- | --- |
| Bugzilla Link | [701](http://bugs.sac-home.org/show_bug.cgi?id=701) |
| Created on | Apr 26, 2010 16:49 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [SCCFprf_modarray11.sac](/uploads/94a6d183d8bf629560c0dbeb4a3bb8c3/SCCFprf_modarray11.sac) |
## Extended Description
<pre>Created an attachment (id=689)
source code to reproduce fault
The SelModArray optimization in CF is intended to take this
common set of expressions:
X = idx_modarray_AxVxS_( M, iv, q);
z = idx_sel_VxA( iv, X);
and turn it into:
z = q;
This optimization is of fundamental importance in loop
fusion/array contraction, and WLF/AWLF, because it allows
us to eliminate intermediate array results.
When a function is compiled with -ecc (or -check c), however,
with my local mods to unroll guards, we end up with this sort
of pattern:
lim = ...;
p0... = {earlier guard(s)}
iv = [ i ];
q = 42;
M' = _modarray_AxVxS_( M, iv, q);
X = _afterguard_( M' , p0...);
i' , p1 = _val_lt_val_SxS_( i, lim);
iv' = [ i'];
z' = _sel_VxA_( iv', X);
z = _afterguard_( z', p1);
We want to map this into:
z = _afterguard( q, p0, p1, ...);
There are several problems here:
1. We don't want to lose the afterguards on p0, p1.
In fact, finding the afterguard on z is a bit of
a problem, if we're looking at the z' computation...
2. We have to chase X back to the M' modarray computation,
through the X afterguard.
3. We have to somehow match iv' and iv, through guards.
This is a unit test from CF, which fails reliably in my local code, if
compiled with:
sac2c -docf -extrema -nowlf -doawlf -ecc SCCFprf_modarray11.sac
This with Build #rev 16795:16801:MODIFIED, which I hope to check in
soon, and fix this one later.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1070Eyeballs suggest that LS never traverses LOCALFUNS2017-11-19T20:20:20ZRobert BerneckyEyeballs suggest that LS never traverses LOCALFUNS| | |
| --- | --- |
| Bugzilla Link | [697](http://bugs.sac-home.org/show_bug.cgi?id=697) |
| Created on | Apr 18, 2010 17:05 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
I just noted this while in...| | |
| --- | --- |
| Bugzilla Link | [697](http://bugs.sac-home.org/show_bug.cgi?id=697) |
| Created on | Apr 18, 2010 17:05 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
I just noted this while introducing LS into SAACYC.
I don't have a failing case, but will adjust the code to
do what I think it should do...BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1069-ecc inhibits CF in SCCFprf_modarray5.sac - need to separate shape vector fro...2017-11-19T20:20:17ZRobert Bernecky-ecc inhibits CF in SCCFprf_modarray5.sac - need to separate shape vector from array| | |
| --- | --- |
| Bugzilla Link | [695](http://bugs.sac-home.org/show_bug.cgi?id=695) |
| Created on | Apr 09, 2010 18:06 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [SCCFprf_modarray5.sac](/uploads/e06...| | |
| --- | --- |
| Bugzilla Link | [695](http://bugs.sac-home.org/show_bug.cgi?id=695) |
| Created on | Apr 09, 2010 18:06 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [SCCFprf_modarray5.sac](/uploads/e06689128120b58da46bab7039b93066/SCCFprf_modarray5.sac) |
## Extended Description
<pre>Created an attachment (id=686)
source code to reproduce fault
I've made some improvements (I hope) in constant folding when -ecc/-check c
are active. The CF unit test SCCFprf_modarray5.sac is intended to eliminate
a sel/modarray pair of operations. This is of fundamental importance in
operations such as loop fusion/array contraction.
When the attached is compiled ( in my version of code with -ecc:
(rev 16776:16792:MODIFIED)), we end up with this IL:
_flat_1 = true;
_flat_0 = 1;
one = _MAIN::id( _flat_0, _flat_1);
_ivexp_92_is = 0;
_isaa_54_one = _dim_A_( one);
_isaa_55_one = _shape_A_( one);
_isaa_56_one = _saabind_( _isaa_54_one, _isaa_55_one, one);
_idc_38, _icc_27_pred = _type_constraint_( int, _isaa_56_one);
_icc_28 = _add_SxS_( _idc_38, _flat_0);
_flat_2 = _afterguard_( _icc_28, _icc_27_pred);
cltwo = _MAIN::id( _flat_2, _flat_1);
_isaa_57_cltwo = _dim_A_( cltwo);
_isaa_58_cltwo = _shape_A_( cltwo);
_isaa_59_cltwo = _saabind_( _isaa_57_cltwo, _isaa_58_cltwo, cltwo);
_flat_5 = 5;
five = _MAIN::id( _flat_5, _flat_1);
_isaa_60_five = _dim_A_( five);
_isaa_61_five = _shape_A_( five);
_isaa_62_five = _saabind_( _isaa_60_five, _isaa_61_five, five);
_idc_39, _icc_29_pred = _type_constraint_( int, _isaa_62_five);
_flat_7 = [:int];
_idc_40, _icc_30_pred = _shape_matches_dim_VxA_( _flat_7, _isaa_59_cltwo);
_icc_33 = _modarray_AxVxS_( _isaa_59_cltwo, _flat_7, _idc_39);
x3 = _afterguard_( _icc_33, _icc_30_pred, _icc_29_pred);
_idc_44, _icc_34_pred = _shape_matches_dim_VxA_( _flat_7, x3);
_icc_37 = _afterguard_( _idc_39, _icc_30_pred, _icc_29_pred);
z = _afterguard_( _icc_37, _icc_34_pred);
_esd_50 = -5;
z__SSA0_1 = _add_SxS_( z, _esd_50);
return( z__SSA0_1);
Note that the function result does not refer to s3 nor to _icc_33, but they are
still with us, because of the presence of guards.
This suggests to me that we might want to change _shape_matches_dim_VxA_()
into something like this:
temps = _idx_shape_sel_( _flat_7);
tempd = _dim_A_( x3);
..._val_matches_val_SxS_(_flat_7, temps, tempd);
What this would do is to eliminate the need to materialize the value
of x3. With any luck, other optimizations would remove the references
to x3 and _Flat_7, and allow them to be removed from the picture as well.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1068Adding CSE,DCR before ICC breaks ICC2017-11-19T20:20:14ZRobert BerneckyAdding CSE,DCR before ICC breaks ICC| | |
| --- | --- |
| Bugzilla Link | [690](http://bugs.sac-home.org/show_bug.cgi?id=690) |
| Created on | Mar 27, 2010 22:31 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [SCSprf_drop2.sac](/uploads/94edbad5...| | |
| --- | --- |
| Bugzilla Link | [690](http://bugs.sac-home.org/show_bug.cgi?id=690) |
| Created on | Mar 27, 2010 22:31 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [SCSprf_drop2.sac](/uploads/94edbad51cace814af14ca3796a88598/SCSprf_drop2.sac) |
## Extended Description
<pre>Created an attachment (id=682)
source code to reproduce fault
I've been tracing a -ecc code problem, and it turns out to be
introduced by a change I made at Rev #16762, to introduce CSE and DCR
immediately before ICC (Phase 9), to eliminate a problem described
in Bug #679.
What happens (Rev #16762 onwards) is that ICC stutters. We get code like this
coming out of -b9:icc:
_idc_68, _icc_44_pred = _val_le_val_VxV_( _idc_66, _idc_67);
_idc_69, _icc_50_pred = _non_neg_val_V_( _idc_68);
_idc_70, _icc_54_pred = _non_neg_val_V_( _idc_69);
_idc_71, _icc_58_pred = _non_neg_val_V_( _idc_70);
This is more or less harmless, but not a good thing to have around.
I'll look into it eventually, but not before April Fools' Day, at the
earliest.
sac2c -ecc SCSprf_drop2.sac -b9:icc > crud
will reproduce the fault. More interesting is that compiling with
-noCSE makes the problem disappear.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1067overloading with different return types only breaks2017-11-19T20:20:10ZSven-Bodo Scholzoverloading with different return types only breaks| | |
| --- | --- |
| Bugzilla Link | [688](http://bugs.sac-home.org/show_bug.cgi?id=688) |
| Created on | Mar 24, 2010 19:01 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [tutu2.sac](/uploads/7f15ba742300038...| | |
| --- | --- |
| Bugzilla Link | [688](http://bugs.sac-home.org/show_bug.cgi?id=688) |
| Created on | Mar 24, 2010 19:01 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [tutu2.sac](/uploads/7f15ba74230003812f2649b41bde8ae3/tutu2.sac) |
## Extended Description
Created an attachment (id=680)
source code
this may be considered illegal; but if so we should give a proper error message
in the compiler.....BugZillaBugZilla