sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T20:21:09Zhttps://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.....BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1066Guarded values do not replace original values in WLs, in rswlfAKD.sac2017-11-19T20:20:06ZRobert BerneckyGuarded values do not replace original values in WLs, in rswlfAKD.sac| | |
| --- | --- |
| Bugzilla Link | [679](http://bugs.sac-home.org/show_bug.cgi?id=679) |
| Created on | Feb 08, 2010 21:19 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug676A.sac](/uploads/fa18f777731e5...| | |
| --- | --- |
| Bugzilla Link | [679](http://bugs.sac-home.org/show_bug.cgi?id=679) |
| Created on | Feb 08, 2010 21:19 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug676A.sac](/uploads/fa18f777731e5f571d49e4015a2babe9/bug676A.sac) |
## Extended Description
<pre>Created an attachment (id=671)
source code to reproduce fault
This is an attempt to separate Bug #676 into its essential parts...
The attached code was compiled under Build #16761:MODIFIED
with these options:
sac2c -extrema -nowlf -doawlf -check c -b11:uglf >crud
The first three options are not relevant, BTW, except for minor
differences in generated code.
Function main() contains this code:
_flat_0 = _MAIN::id( _flat_1);
_isaa_695__flat_0 = _saabind_( _isaa_675__rso_6_TheWorld, _isaa_676__rso_6_TheWorld, _flat_0);
_pinl_507__flat_5 = [ _isaa_695__flat_0 ];
_pinl_516__idc_68, _pinl_515__icc_61_pred = _non_neg_val_V_( _pinl_507__flat_5);
_pinl_510__flat_2 = [ 0 ];
_pinl_518__idc_69, _pinl_517__icc_60_pred = _non_neg_val_V_( _pinl_510__flat_2);
_pinl_523__idc_72, _pinl_522__icc_63_pred = _val_le_val_VxV_( _pinl_518__idc_69, _pinl_507__flat_5);
_pinl_528__idc_75, _pinl_527__icc_65_pred = _val_le_val_VxV_( _pinl_516__idc_68, _pinl_507__flat_5);
_pinl_575_ub_i = _max_SxS_( _isaa_675__rso_6_TheWorld, _isaa_695__flat_0);
_pinl_540__wlbsc_490_sc_bound = [ _pinl_575_ub_i ];
_wlsimp_608 = _sub_SxS_( _isaa_695__flat_0, _pinl_575_ub_i);
_pinl_506__icc_67 = with {
(_pinl_540__wlbsc_490_sc_bound <= _pinl_513__flat_6=[_pinl_514_i] < _pinl_507__flat_5 genwidth [ _wlsimp_608 ])
{
/* empty */
} : _isaa_675__rso_6_TheWorld ; ,
(_pinl_510__flat_2 <= _pinl_513__flat_6=[_pinl_514_i] < _pinl_507__flat_5 genwidth [ _isaa_695__flat_0 ])
{
/* empty */
} : _pinl_514_i ;
} :
genarray( _pinl_507__flat_5, _isaa_675__rso_6_TheWorld);
Several things are notable in this code:
1. The unguarded result of id(), _isaa_695__flat_0, is used as WL
GENERATOR_BOUND2 and in the _max_SxS_() computation.
Although semantically correct, due to the _afterguard_() that follows
the WL (not shown), it means that using the _non_neg_val_() guard
as the basis for annotating _pinl_516__idc_68 with
an AVIS_MINVAL() of zero does us no good in simplifying the
_max_SxS_() computation.
2. Similarly, the vector result of the val_le_val_VxV_() computation is
not used at all. Its semantics are saved only by the use of
its predicate result in the trailing _afterguard_().
What should be done here, I think, is the following;
Each guard should, effectively, replace all following occurrences of its
vector arguments by the appropriate result of that guard.
This would have the effect of allowing array annotations (e.g.,
AVIS_MINVAL, AVIS_MAXVAL) to propagate through the code from each
guard to the actual point(s) of use of the putative variable.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1065Crash in Applying Loop Scalarization on tvd2d_abstract2017-11-19T20:20:02ZDaniel RollsCrash in Applying Loop Scalarization on tvd2d_abstract| | |
| --- | --- |
| Bugzilla Link | [677](http://bugs.sac-home.org/show_bug.cgi?id=677) |
| Created on | Feb 05, 2010 17:43 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [tvd2d_abstract.sac](/uploads/5779b9e2...| | |
| --- | --- |
| Bugzilla Link | [677](http://bugs.sac-home.org/show_bug.cgi?id=677) |
| Created on | Feb 05, 2010 17:43 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [tvd2d_abstract.sac](/uploads/5779b9e2a2145c8d08ceaa9960c21d8a/tvd2d_abstract.sac), [fluid.tar.bz2](/uploads/cf720010034eaff2820cbc1d339e3b99/fluid.tar.bz2) |
## Extended Description
<pre>Created an attachment (id=668)
sac source code (large)
developer rev 16752:MODIFIED
Carl's build on Obelix as of 5/2/10.
sac2c tvd2d_abstract.sac -Lfluid -maxoptcyc 2
Crash when Applying Loop Scalarization.
This code is large and I may need to reduce its size before this bug can be investigated.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1064WLPartitionGenerator generates overlapping partitions2017-11-19T20:19:58ZRobert BerneckyWLPartitionGenerator generates overlapping partitions| | |
| --- | --- |
| Bugzilla Link | [676](http://bugs.sac-home.org/show_bug.cgi?id=676) |
| Created on | Feb 04, 2010 19:48 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bugx.sac](/uploads/5d93751c670896ca...| | |
| --- | --- |
| Bugzilla Link | [676](http://bugs.sac-home.org/show_bug.cgi?id=676) |
| Created on | Feb 04, 2010 19:48 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bugx.sac](/uploads/5d93751c670896cab4ded7fada7f54b5/bugx.sac) |
## Extended Description
<pre>Created an attachment (id=667)
source code to reproduce fault
If I compile the attached with Build #16757, this way:
sac2c bugx.sac -b11:uglf >crud
I get this for main():
_flat_1 = 25;
_flat_0 = _MAIN::id( _flat_1);
_isaa_264__flat_0 = 0;
_isaa_265__flat_0 = [:int];
_isaa_266__flat_0 = _saabind_( _isaa_264__flat_0, _isaa_265__flat_0, _flat_0);
_pinl_135__flat_5 = [ _isaa_266__flat_0 ];
_pinl_138__flat_2 = [ 0 ];
AAA = with {
(_pinl_138__flat_2 <= _pinl_141__flat_6=[_pinl_142_i] < _pinl_135__flat_5 genwidth [ _isaa_266__flat_0 ])
{
/* empty */
} : _pinl_142_i ;
} :
genarray( _pinl_135__flat_5, _isaa_264__flat_0);
_flat_2 = 5;
_pinl_214_ub_i = _max_SxS_( _isaa_264__flat_0, _isaa_266__flat_0);
_pinl_179__wlbsc_125_sc_bound = [ _pinl_214_ub_i ];
_wlsimp_231 = _sub_SxS_( _isaa_266__flat_0, _pinl_214_ub_i);
_pinl_165_zPLUS = with {
(_pinl_179__wlbsc_125_sc_bound <= _pinl_162_iv=[_pinl_166__eat_11] < _pinl_135__flat_5 genwidth [ _wlsimp_231 ])
{
_pinl_226__flat_147 = _sel_VxA_( _pinl_162_iv, AAA);
} : _pinl_226__flat_147 ; ,
(_pinl_138__flat_2 <= _pinl_162_iv=[_pinl_166__eat_11] < _pinl_135__flat_5 genwidth [ _isaa_266__flat_0 ])
{
_pinl_200__flat_95 = _sel_VxA_( _pinl_162_iv, AAA);
_pinl_189__flat_213 = _add_SxS_( _pinl_200__flat_95, _flat_2);
} : _pinl_189__flat_213 ;
} :
modarray( AAA);
z = _sel_VxA_( _pinl_138__flat_2, _pinl_165_zPLUS);
_esd_236 = -5;
_pinl_204__flat_212 = _add_SxS_( z, _esd_236);
return( _pinl_204__flat_212);
}
Note that the _pinl_165_zPLUS Wl has duplicate GENERATOR_BOUND2 values.
Note also that the max() computation of _pinl_214_ub_i is not
reducible. This screws AWLF.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1063propagate seems to have propagated a lot in buildv.sac2017-11-19T20:19:54ZRobert Berneckypropagate seems to have propagated a lot in buildv.sac| | |
| --- | --- |
| Bugzilla Link | [673](http://bugs.sac-home.org/show_bug.cgi?id=673) |
| Created on | Jan 14, 2010 16:18 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [tomcatv.sac](/uploads/a8504d9edda00...| | |
| --- | --- |
| Bugzilla Link | [673](http://bugs.sac-home.org/show_bug.cgi?id=673) |
| Created on | Jan 14, 2010 16:18 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [tomcatv.sac](/uploads/a8504d9edda003a0477c38dee3371c21/tomcatv.sac), [mconv.sac](/uploads/b1fe4a91e6bb61c6c008a0f4a0ff06e8/mconv.sac), [crud.breaks.sac](/uploads/ec84bfd95301176831a8c68167d7f808/crud.breaks.sac) |
## Extended Description
<pre>Created an attachment (id=661)
Source code to reproduce fault
I've started seeing weird "propagate" stuff appearing in my -b11:ebt
output of late. I have no idea where it came from.
This is with Build #16723, with "sac2c buildv.sac -b11:ebt -O3 sac/apex/mconv/mconv.sac":
_pinl_12164_z, _pinl_10186__rso_250_TheTerminal__SSA0_3 = with {
(_pinl_12255__flat_2 <= _pinl_12160_iv=[_pinl_12169__eat_333] < _pinl_12252__flat_5 genwidth [ 100 ])
{
_pinl_12165__rso_287_TheTerminal__SSA0_1 = _prop_obj_in_( _pinl_12160_iv, _pinl_10185__rso_250_TheTerminal__SSA0_2);
_pinl_12188__flat_95 = _sel_VxA_( _pinl_12160_iv, _pinl_12203_z);
_pinl_13107__flat_9 = _tod_S_( _pinl_12188__flat_95);
_pinl_13111__flat_195 = _mul_SxS_( _pinl_10172__flat_9, _pinl_13107__flat_9);
_pinl_12168__rso_287_TheTerminal__SSA0_4 = _prop_obj_out_( _pinl_12165__rso_287_TheTerminal__SSA0_1);
} : _pinl_13111__flat_195, _pinl_12168__rso_287_TheTerminal__SSA0_4 ;
} :
genarray( _pinl_12252__flat_5, _pinl_12158__flat_190),
propagate( _pinl_10185__rso_250_TheTerminal__SSA0_2);
It happens with the latest Build #16731, so I backed up in some a bit to
see if my recent changes caused it. Apparently not.
Suggestions welcome.</pre>BugZillaBugZilla