sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T20:19:03Zhttps://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/1309WLS screws up default partition2017-11-19T20:37:32ZSven-Bodo ScholzWLS screws up default partition| | |
| --- | --- |
| Bugzilla Link | [596](http://bugs.sac-home.org/show_bug.cgi?id=596) |
| Created on | Nov 18, 2009 02:01 |
| Version | 1.00beta |
| OS | All |
| Architecture | PC |
| Attachments | [CalcCohCoefs.sac](/uploads/cc8c6...| | |
| --- | --- |
| Bugzilla Link | [596](http://bugs.sac-home.org/show_bug.cgi?id=596) |
| Created on | Nov 18, 2009 02:01 |
| Version | 1.00beta |
| OS | All |
| Architecture | PC |
| Attachments | [CalcCohCoefs.sac](/uploads/cc8c6e22ca9785a7aa075ad11a8ffc73/CalcCohCoefs.sac) |
## Extended Description
<pre>Created an attachment (id=606)
source file
compilation with sac2c rev 16578 calling
sac2c CalcCohCoefs.sac
yields
ERROR: line 43
ERROR: Shape of argument #1 of "_sel_VxA_" should match dimensionality of
ERROR: argument #2; types found: int[1] and double[28,2]
which is wrong!
However, before WLS, eg after b10, the code was still correct.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1225UTMScalarI.sac breaks under AWLF2017-11-19T20:32:09ZRobert BerneckyUTMScalarI.sac breaks under AWLF| | |
| --- | --- |
| Bugzilla Link | [593](http://bugs.sac-home.org/show_bug.cgi?id=593) |
| Created on | Nov 13, 2009 23:04 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/4f60685f279...| | |
| --- | --- |
| Bugzilla Link | [593](http://bugs.sac-home.org/show_bug.cgi?id=593) |
| Created on | Nov 13, 2009 23:04 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/4f60685f27901934c14b4f7f5eb3cc61/crud.sac) |
## Extended Description
<pre>The attached abbreviated version of UTTakeDrop.sac has
at least two problems when compiled with Build#16545:MODIFIED
and -nowlf -doawlf -extrema
1. match(x,y) returns the wrong answer, although x==y works properly.
2. The fold WL that is the cause of the problem (It happens to be
indexing into a 20-element array that is only 10 elements long,
for example...) has two results, but one of the results is
dead code.
WLF works properly.
I'll look at it tomorrow.</pre>Robert BerneckyRobert Berneckyhttps://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/1293rc cases descriptor to be freed2017-11-19T20:36:15ZCarl Joslinrc cases descriptor to be freed| | |
| --- | --- |
| Bugzilla Link | [582](http://bugs.sac-home.org/show_bug.cgi?id=582) |
| Created on | Oct 29, 2009 11:37 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug582.sac](/uploads/0005ad76e...| | |
| --- | --- |
| Bugzilla Link | [582](http://bugs.sac-home.org/show_bug.cgi?id=582) |
| Created on | Oct 29, 2009 11:37 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug582.sac](/uploads/0005ad76eed54073a7bb73ad1b58e33f/bug582.sac), [bunzip2.sac](/uploads/9420e3b3a08d5a598c1963d09b9e7e43/bunzip2.sac) |
## Extended Description
<pre>The attached code produces the function:
SACf__MAIN__decode__i_488__i
this function passes a pointer to an uninitialised descriptor and array to the function:
SACf__MAIN__get_bits__i_488__i__i
for use as the return value.
SACf__MAIN__get_bits__i_488__i__i seems to create the needed descriptor and array and passes them to:
SACf__MAIN__compare__i_X__i_6
The first time it does this every thing seems fine the rc goes up and back down however when it calls:
SACf__MAIN__compare__i_X__i_6
the second time it just goes down and not up.
As a result the descripter is freeded and there for not returned by:
SACf__MAIN__get_bits__i_488__i__i
and then when SACf__MAIN__decode__i_488__i uses the memory the program segfalts.</pre>Carl JoslinCarl Joslinhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1192wlsd can not handle MG2017-11-19T20:29:25ZCarl Joslinwlsd can not handle MG| | |
| --- | --- |
| Bugzilla Link | [579](http://bugs.sac-home.org/show_bug.cgi?id=579) |
| Created on | Oct 27, 2009 15:56 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [mg_rotate_sl.sac](/uploads/12c...| | |
| --- | --- |
| Bugzilla Link | [579](http://bugs.sac-home.org/show_bug.cgi?id=579) |
| Created on | Oct 27, 2009 15:56 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [mg_rotate_sl.sac](/uploads/12c823c1961b3fb971d3c6ab53466d25/mg_rotate_sl.sac) |
## Extended Description
<pre>LWSD has problems processing a grid:
ASSERTION FAILED: file 'wltransform/wl_split_dimensions.c', line 2120
neither code nor nextdim?
EXECUTION TERMINATED
Aborted
sac2c v1.00-beta (Buchette d'Anjou)
developer rev 16497 linux-gnu_i686
(Tue Oct 27 13:17:09 GMT 2009 by caj)</pre>Carl JoslinCarl Joslinhttps://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/1191WLSD does not upgrade types2017-11-19T20:29:22ZCarl JoslinWLSD does not upgrade types| | |
| --- | --- |
| Bugzilla Link | [558](http://bugs.sac-home.org/show_bug.cgi?id=558) |
| Created on | Aug 28, 2009 12:48 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [fold.sac](/uploads/79a1adf2fd8...| | |
| --- | --- |
| Bugzilla Link | [558](http://bugs.sac-home.org/show_bug.cgi?id=558) |
| Created on | Aug 28, 2009 12:48 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [fold.sac](/uploads/79a1adf2fd8cafe6acb02c9a46201998/fold.sac) |
## Extended Description
<pre>Created an attachment (id=564)
Example code to produce error.
WLSD does not produce the most precise types possible for inner with3s this then affects RW3.
Problem happens when the set of with3s produce an akd but when sub with3s can produce aks.
int[.] _anonymous_2220 { } ;
int[.] res { } ;
res = with3 {
(0 <= _wlsd_2211 < _flat_843 in 1 (IDXS: _wlsd_2212) ) /* (BS: 0) */ {
...
_anonymous_2220 = with3 {
(0 <= _wlsd_2215 < 1 in 1 (IDXS: _wlsd_2216) ) /* (BS: 0) */ {
...
} : _flat_853;
} : ( genarray( [ 1 ] , genarray( [:int] ,_flat_849)));
} : _anonymous_2220;
...
} : ( genarray( [ _flat_842 ] , genarray( [:int] ,_flat_849)));
In the above example _anonymous_2220 should be [1] not [.]. This seems to stem from the type of _anonymous_2220 coming from res and not the with3 that it is defined from.</pre>Carl JoslinCarl Joslinhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1303ArrayFormat dies dismally on double data2017-11-19T20:37:04ZRobert BerneckyArrayFormat dies dismally on double data| | |
| --- | --- |
| Bugzilla Link | [555](http://bugs.sac-home.org/show_bug.cgi?id=555) |
| Created on | Aug 14, 2009 22:49 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bugformat.sac](/uploads/e1277f...| | |
| --- | --- |
| Bugzilla Link | [555](http://bugs.sac-home.org/show_bug.cgi?id=555) |
| Created on | Aug 14, 2009 22:49 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bugformat.sac](/uploads/e1277f223ffe2eb57565bd227950cd86/bugformat.sac) |
## Extended Description
<pre>sac2c Build #16335
int main()
{
v = [ 9.884995e+06, 1.031330e+14, 9.885003e+06, 1.082900e+14 ];
StdIO::print(v);
StdIO::show(v);
return(0);
}
produces this:
a.out
Dimension: 1
Shape : < 4>
<9.884995e+06 1.031330e+14 9.885003e+06 1.082900e+14 >
*** SAC runtime error
*** line 152
*** argument #1 of "_sel_VxA_" should be legal index into argument #2;
*** types found: int[1]{1} and char[1]
Clearly, double vector formatting code needs work.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1308UTCompress crashes in WLBnodeOrIntGetNameOrVal2017-11-19T20:37:28ZRobert BerneckyUTCompress crashes in WLBnodeOrIntGetNameOrVal| | |
| --- | --- |
| Bugzilla Link | [552](http://bugs.sac-home.org/show_bug.cgi?id=552) |
| Created on | Aug 13, 2009 23:20 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTCompress.sac](/uploads/a77c7...| | |
| --- | --- |
| Bugzilla Link | [552](http://bugs.sac-home.org/show_bug.cgi?id=552) |
| Created on | Aug 13, 2009 23:20 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTCompress.sac](/uploads/a77c7b0b6d1b98f808a67d5948b7a79f/UTCompress.sac) |
## Extended Description
<pre>Created an attachment (id=557)
Source code to cause crash
If compiled this way:
sac2c v1.00-beta (Buchette d'Anjou)
developer rev 16326 linux-gnu_x86_64
(Thu Aug 13 16:01:15 EDT 2009 by sac)
apex@rattler:~/apex2003/benchmks/UTCompress$ sac2c -extrema -nowlf -doswlf -v3 UTCompress.sac
the attached sac program dies generating intermediate code macros
inside WLBnodeOrIntGetNameOrVal.</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/1290Failure to move invariant WL out of FOR loop kills ipbb performance2017-11-19T20:36:02ZRobert BerneckyFailure to move invariant WL out of FOR loop kills ipbb performance| | |
| --- | --- |
| Bugzilla Link | [524](http://bugs.sac-home.org/show_bug.cgi?id=524) |
| Created on | Jul 14, 2009 04:10 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbb5.slow.sac](/uploads/8d7e3...| | |
| --- | --- |
| Bugzilla Link | [524](http://bugs.sac-home.org/show_bug.cgi?id=524) |
| Created on | Jul 14, 2009 04:10 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbb5.slow.sac](/uploads/8d7e3284e351038555e32585e81d58f7/ipbb5.slow.sac), [bug.funcond.sac](/uploads/510d31f8fba7844dbf4f0fbee5906001/bug.funcond.sac), [bug.compress.breaks.sac](/uploads/828cbca7dac5c005d9f146e53b821e5e/bug.compress.breaks.sac), [iotaonly7.sac](/uploads/f5ee8367f580cbb69881f909b89fc95d/iotaonly7.sac), [crud.slow](/uploads/2cecdb609f665609e8d7170337f12222/crud.slow), [crud.fast](/uploads/4755e5b361dd6e17fbb26472a2aff788/crud.fast) |
## Extended Description
<pre>Created an attachment (id=551)
Shorter source code to reproduce fault
I've been chasing a problem with the performance of a Boolean-Boolean
inner product code, apex/ipbb/ipbb.sac.
Although I think there are some problems with my extrema code in
this area, due to differences in performance in the current system,
the attached shorter example has the interesting property that
the compiler does not appear to be moving a loop-invariant Wl out of a
FOR-loop.
I say this because, if I move the loop out by hand, everything
runs bags faster in both the extrema and non-extrema world.
I am off to bed, so have not looked into this yet...
This all with Build #16193.
With xrow inside FOR-loop:
sac2c -O3:
ipbb5.slow.sac.exe.O3.papiex.rattler.28893:PAPI_TOT_INS: 99065594
sac2c -O3 -extrema -nowlf -doswlf:
ipbb5.slow.sac.exe.swlf.papiex.rattler.28928:PAPI_TOT_INS: 1003065073
With xow outside FOR-loop:
sac2c -O3:
ipbb5.slow.sac.exe.O3.papiex.rattler.28998:PAPI_TOT_INS: 765065354
sac2c -O3 -extrema -nowlf -doswlf:
ipbb5.slow.sac.exe.swlf.papiex.rattler.28970:PAPI_TOT_INS: 765065175</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1302Code slowdown depending on where scalar comes from2017-11-19T20:37:00ZRobert BerneckyCode slowdown depending on where scalar comes from| | |
| --- | --- |
| Bugzilla Link | [522](http://bugs.sac-home.org/show_bug.cgi?id=522) |
| Created on | Jul 08, 2009 16:53 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [slow2.breaks.sac](/uploads/f38...| | |
| --- | --- |
| Bugzilla Link | [522](http://bugs.sac-home.org/show_bug.cgi?id=522) |
| Created on | Jul 08, 2009 16:53 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [slow2.breaks.sac](/uploads/f38ee1bee9c044bb767c95d69c70e0d9/slow2.breaks.sac), [iotaonly4.sac](/uploads/16e3842a7592d98a1f60bff4449cbd7d/iotaonly4.sac), [crud.breaks.sac](/uploads/61f4b374c6c3433f7d2dcf91adfa61b0/crud.breaks.sac), [iotaonly4.fast.O3.c](/uploads/2aa1529941780c95d3e4a8f7e5f3c242/iotaonly4.fast.O3.c), [iotaonly4.slow.O3.c](/uploads/55d9c175ae8ab695f5e1a96e0c157b05/iotaonly4.slow.O3.c), [iotaonly8.sac](/uploads/f5d701be0d4ed5775ce7e0e27a41a5b5/iotaonly8.sac), [iotaonly8.slow.b11](/uploads/f3d6b0ca3d2a08a09e6ad35b23d8f10d/iotaonly8.slow.b11), [iotaonly8.fast.b11](/uploads/a84616ed216c1cecd72f38c7b08ad150/iotaonly8.fast.b11), [iotaonly9.sac](/uploads/0506eb9821afebe8d3f201dd80175eef/iotaonly9.sac) |
## Extended Description
<pre>Created an attachment (id=550)
Shorter source code to reproduce fault
The attached code presents, I think, two problems:
The code performs +/⍳n; i.e., sum the first n integers.
1. If n comes from an id() function, both codes perform alike
when compiled with:
-O3
and
-O3 -nowlf -doswlf -extrema
2. If n comes from reading the command line, the code compiled with -O3
performs about 15% faster than the SWLF code.
Eyeballing the -b11 output did not give me any hints as to a difference
in generated code, EXCEPT that the WLF code contains TWO WLs, but
the SWLF code contains only one WL, it having folded the two WLs together.
Also, the second WL in the WLF-generated code has an RC(xxx) in its
WITHOP genarray clause. What does this RC field mean? Could that be
relevant?
I saw this problem before, but don't see any bugzilla entry for it.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2138three dots as arguments unsafer than expected2021-08-30T15:56:59ZSven-Bodo Scholzthree dots as arguments unsafer than expected| | |
| --- | --- |
| Bugzilla Link | [521](http://bugs.sac-home.org/show_bug.cgi?id=521) |
| Created on | Jul 07, 2009 14:45 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [tutu.sac](/uploads/6e449df16f5...| | |
| --- | --- |
| Bugzilla Link | [521](http://bugs.sac-home.org/show_bug.cgi?id=521) |
| Created on | Jul 07, 2009 14:45 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [tutu.sac](/uploads/6e449df16f5940c2e6e5d42fd468ef60/tutu.sac) |
## Extended Description
<pre>Created an attachment (id=549)
source code
compile with -maxspec 0 and the 5.0 will be printed as 0.0000.
The reason for this is that the scalar value comes as AUD and therefore
in boxed form. As it is in ... position of printf, precompile cannot
insert appropriate casts to make sure an unboxed double is passed to the
actual printf implementation.
inlining or specialisations obviously make this problem go away....</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1301EWLF can lose AVIS_SHAPE/DIM information in N_ap invocation2017-11-19T20:36:49ZRobert BerneckyEWLF can lose AVIS_SHAPE/DIM information in N_ap invocation| | |
| --- | --- |
| Bugzilla Link | [514](http://bugs.sac-home.org/show_bug.cgi?id=514) |
| Created on | Jun 23, 2009 22:02 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug514.breaks.sac](/uploads/a0...| | |
| --- | --- |
| Bugzilla Link | [514](http://bugs.sac-home.org/show_bug.cgi?id=514) |
| Created on | Jun 23, 2009 22:02 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug514.breaks.sac](/uploads/a01bc6855aeac1c5be0008037256a58a/bug514.breaks.sac), [crud3.sac](/uploads/c1baeae82c3769f27f33321906a9e38f/crud3.sac) |
## Extended Description
<pre>Created an attachment (id=543)
Source code to reproduce fault
If I compile the attached with: sac2c -nowlf -extrema -doswlf,
ive_split_selections complains because it does not have
AVIS_SHAPE/DIM information for Loop_4 argument x.
The calling environment DOES have that information, so something
in saacyc and EWLF is doing bad stuff.
This is noticable inasmuch as it causes your basic factor-of-50
slowdown in the binary search code used in APEX set membership,
indexof, and elsewhere.</pre>Robert BerneckyRobert Berneckyhttps://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>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1040CSE misses cases on LACFNS in apex/mconvout2017-11-19T20:18:32ZRobert BerneckyCSE misses cases on LACFNS in apex/mconvout| | |
| --- | --- |
| Bugzilla Link | [511](http://bugs.sac-home.org/show_bug.cgi?id=511) |
| Created on | Jun 17, 2009 23:41 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The following is...| | |
| --- | --- |
| Bugzilla Link | [511](http://bugs.sac-home.org/show_bug.cgi?id=511) |
| Created on | Jun 17, 2009 23:41 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The following is a fragment of code generated by the apex/mconvout/mconvout.sac benchmark. I see several problems with this code:
1. CSE (I think) fails to note that _flat_134 and _flat_137 are
identical, as are the sel() operations that follow them.
I would expect, as a first step, to move the common code out of
the conditional and into the code that dominates it.
2. As a second step, the indexing operation should be totally
lifted out of Cond_3 and into the calling environment.
This would eliminate the need for k, and i,
to be passed into Cond_3.
I am not sure how much this might affect run-time performance, but I stumbled
across this while searching for your basic factor-of-4 slowdown.
This isn't it, sadly enough, because it appears in both my fast and slow
cases.
-----------------------------------------------------------------------------
int _MAIN::_dup_13852______rotrIDD__Cond_3( int[100] k { } , int i { } , int j { } , bool _flat_129 { } )
/*
* _dup_13852______rotrIDD__Cond_3 :: ---
*/
{
int _pinl_10860__flat_95 { } ;
int _pinl_10861__flat_69 { } ;
int _pinl_10862__flat_68 { } ;
int _pinl_10855__flat_95 { } ;
int _pinl_10856__flat_69 { } ;
int _hce_1__SSA0_2 { } ;
int[1] _flat_134 { } ;
int[1] _flat_137 { } ;
if (_flat_129)
{
_flat_134 = [ i ];
_pinl_10855__flat_95 = _sel_VxA_( _flat_134, k);
_pinl_10856__flat_69 = _add_SxS_( j, _pinl_10855__flat_95);
}
else
{
_flat_137 = [ i ];
_pinl_10860__flat_95 = _sel_VxA_( _flat_137, k);
_pinl_10861__flat_69 = _add_SxS_( j, _pinl_10860__flat_95);
_pinl_10862__flat_68 = _sub_SxS_( _pinl_10861__flat_69, 350099);
}
_hce_1__SSA0_2 = ( _flat_129 ? _pinl_10856__flat_69 : _pinl_10862__flat_68 );
return( _hce_1__SSA0_2);
}</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1039GLF: Generally Lousy FLOPs rate?2017-11-19T20:18:28ZRobert BerneckyGLF: Generally Lousy FLOPs rate?| | |
| --- | --- |
| Bugzilla Link | [506](http://bugs.sac-home.org/show_bug.cgi?id=506) |
| Created on | Jun 06, 2009 22:49 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/79660830e09...| | |
| --- | --- |
| Bugzilla Link | [506](http://bugs.sac-home.org/show_bug.cgi?id=506) |
| Created on | Jun 06, 2009 22:49 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/79660830e097434fc5739a4e5abe1ba6/crud.sac) |
## Extended Description
<pre>-glf as default turned out to show up several problems.
Among them were several APEX benchmarks, including compiotaAKD.sac,
which started running 10X slower and eating all the memory on my system.
Here's a trimmed version excised from here, limited to just the
APL reshape (genarray-ish) that shows the problem.
With Build #16124 (containing many Bodo fixes already), the code leaves
some sacprelude::sel() wrapper functions in the code. This not
only slows things down, but inhibits WLF and EWLF.</pre>BugZillaBugZilla