sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T20:33:19Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1245Livermore Loop loop09 sparse matrix multiply performance problem w/ -dolacsi2017-11-19T20:33:19ZRobert BerneckyLivermore Loop loop09 sparse matrix multiply performance problem w/ -dolacsi| | |
| --- | --- |
| Bugzilla Link | [1052](http://bugs.sac-home.org/show_bug.cgi?id=1052) |
| Created on | Mar 14, 2013 15:27 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [loop09A.sac](/uploads/9fae5685b6d...| | |
| --- | --- |
| Bugzilla Link | [1052](http://bugs.sac-home.org/show_bug.cgi?id=1052) |
| Created on | Mar 14, 2013 15:27 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [loop09A.sac](/uploads/9fae5685b6d70500f2132b44a2a85af4/loop09A.sac) |
## Extended Description
<pre>Created an attachment (id=952)
source code to reproduce fault
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
product rev 18069 linux-gnu_x86_64
(Wed Mar 13 17:40:45 EDT 2013 by sac)
I have made the SAC and C versions of loop09 match again, in the sense
that they return the same results. I have also reverted loop09 to the
earlier, imperative version, and created loop09A, a version that uses
the sparse vector-matrix multiply that I use in APEX.
Results are good, Almost... Here are the CPU times and cache miss rates
for same:
sac2c loop09A.sac -O3 -dolacsi -doawlf -nowlf -O3
CPU (usec) L1miss L2miss
loop09.c 2210390 20547020 1304
wlf loop09.sac 5228058 20041898 5567
awlf loop09.sac 2388230 19047599 2421
wlf loop09A.sac 10575784 64461221 6619
awlf loop09A.sac 4779216 105809057 3539
It is the last line that is puzzling. IMO, its performance should be
extremely close to that of the third line. But, it ain't.
What is going on is, essentially, this:
- Originally, Cond_0() in the inner loop is passed a 1-element vector V.
It uses V0=V[0] as GENERATOR_BOUND2( [V0]) and GENARRAY_SHAPE( [ V0]).
- -dolacsi allows elimination of the sel V0 = V[0],
- Someone (SAA?) generates V' = [ V0] as the result shape of the
Cond_0 result.
- Eventually, we end up with a funcond at the end of Cond_0(),
roughly of this form:
V' = [ V0];
shp = flat_1 ? V' : V;
Both legs of the funcond match, so this is really just: shp = V.
That should get shp lifted out of Cond_0(), but nothing has
enough smarts to do that.
We end up, therefore, with all this baggage in the inner loop,
of which the building of V' is causing most of the harm.
Possible actions:
1. I do not think we can do much in LACSI about these things.
The shp-related code goes through a lot of optimization before
we get to the point above.
2. We do happen to have AVIS_SCALARS( V) = [ V0]. It should be possible
to make CF or one of its buddies that looks at funconds check to see
if one funcond argument is an N_array that matches the AVIS_SCALARS
of the other and, if so, replace things appropriately:
shp = flat_1 ? V : V;
[Premature replacement by: shp = V; is bad, because of the delicate
nature of the funcond structure. That will get done elsewhere.]
The latter is fairly straightforward, so I'm going to try that approach.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1244Livermore Loop loop09.sac sparse matrix multiply sensitive to argument ordering2017-11-19T20:33:15ZRobert BerneckyLivermore Loop loop09.sac sparse matrix multiply sensitive to argument ordering| | |
| --- | --- |
| Bugzilla Link | [1051](http://bugs.sac-home.org/show_bug.cgi?id=1051) |
| Created on | Mar 08, 2013 18:44 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This sparse matrix ...| | |
| --- | --- |
| Bugzilla Link | [1051](http://bugs.sac-home.org/show_bug.cgi?id=1051) |
| Created on | Mar 08, 2013 18:44 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This sparse matrix kernel in loop09.sac exhibits an undesirable sensitivity to
argument ordering:
inline double[.] vecmatmul( double[.] wts, double[.,.] PX) {
/* Sparse wts matrix multiply: wts f.g PX */
colsx = shape(wts)[0];
colsy = shape(PX)[1];
z = genarray([colsy], 0.0d);
for (colx=0; colx<colsx; colx++) {
if (0.0 != wts[colx]) { /* Skip iteration if it's an f identity */
z = z + wts[colx] * PX[colx];
}
}
return(z);
}
In particular, AWLF fails for the computation of z within the if(),
because the stdlib dyadic scalar function code was depending on
shape(z), rather than the shape of its right argument. Comments:
1. The array shapes are conformable for inner product, but LIR and
friends make it difficult for AWLF to deduce that the two genarray
shapes do, indeed, match.
2. I changed the stdlib dyadic scalar template to use the right argument
shape, because I think that should improve the chances of AWLF working
in typical function compositions, such as A + ( B * C).
3. Compiling with -dolacsi and/or -dolacso did not help.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2139APEX benchmark shortened snp.sac gets stuck in WLUR during opt cycle 22017-11-19T22:01:34ZRobert BerneckyAPEX benchmark shortened snp.sac gets stuck in WLUR during opt cycle 2| | |
| --- | --- |
| Bugzilla Link | [1050](http://bugs.sac-home.org/show_bug.cgi?id=1050) |
| Created on | Mar 06, 2013 16:17 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/8f0267bd90f82b...| | |
| --- | --- |
| Bugzilla Link | [1050](http://bugs.sac-home.org/show_bug.cgi?id=1050) |
| Created on | Mar 06, 2013 16:17 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/8f0267bd90f82bb97a3b5c43dfccef3f/crud.sac) |
## Extended Description
<pre>Created an attachment (id=951)
source code to reproduce fault
Summary says it all:
**** Optimization cycle pass: 2
****** Optimizing regular function:
****** _MAIN::main( hidden(1), hidden(2), hidden(0)): ...
...
WLUR: -maxwlur 3 would unroll genarray with-loop
WLUR: -maxwlur 3 would unroll genarray with-loop
^CAborted
apex@rattler:~/apex3/benchmks/snp$ vi crud.sac
apex@rattler:~/apex3/benchmks/snp$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18061 linux-gnu_x86_64
(Fri Mar 1 17:24:54 EST 2013 by sac)
apex@rattler:~/apex3/benchmks/snp$ sac2c crud.sac -doawlf -nowlf -v1 -O3 -v4 -maxwlur 1</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1243APEX benchmark UTCompress.sac dies in EBT2017-11-19T20:33:11ZRobert BerneckyAPEX benchmark UTCompress.sac dies in EBT| | |
| --- | --- |
| Bugzilla Link | [1049](http://bugs.sac-home.org/show_bug.cgi?id=1049) |
| Created on | Mar 01, 2013 22:31 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>With this version o...| | |
| --- | --- |
| Bugzilla Link | [1049](http://bugs.sac-home.org/show_bug.cgi?id=1049) |
| Created on | Mar 01, 2013 22:31 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>With this version of SAC:
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18061 linux-gnu_x86_64
(Fri Mar 1 17:24:54 EST 2013 by sac)
and this command line:
sac2c-d crud.sac -doawlf -nowlf -v4
use Array: all;
int main()
{
y=genarray([2, 3, 4],5);
sy = shape(y);
Z = (true == (false)) ? y : genarray(drop([-1],sy)++[0],0);
StdIO::print( Z);
return(0 );
}
sac2c dies in -bopt:cyc:ebt:3.
Since it compiles OK if you leave off the -doawlf, I presume this is
my doing.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1267vector shift() produces strange WL partitions2017-11-19T20:34:36ZRobert Berneckyvector shift() produces strange WL partitions| | |
| --- | --- |
| Bugzilla Link | [1048](http://bugs.sac-home.org/show_bug.cgi?id=1048) |
| Created on | Feb 27, 2013 22:56 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud4.sac](/uploads/ab5ee1bada151...| | |
| --- | --- |
| Bugzilla Link | [1048](http://bugs.sac-home.org/show_bug.cgi?id=1048) |
| Created on | Feb 27, 2013 22:56 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud4.sac](/uploads/ab5ee1bada1518775bb99cde1e55d840/crud4.sac) |
## Extended Description
<pre>Created an attachment (id=948)
source code to reproduce fault
This WL has three partitions, but the first one is, supposedly, degenerate:
_pinl_964__icc_698 = with {
([ _pinl_1147_z ] <= _pinl_975_iv=[_pinl_981__eat_24] < [ N__SSA0_2 ] genwidth [ _wlsimp_1161 ])
{
} : _flat_21 ; ,
([ 0 ] <= _pinl_975_iv=[_pinl_981__eat_24] < [ _uprf_1209 ] genwidth [ _uprf_1209 ])
{
} : _flat_21 ; ,
([ _uprf_1209 ] <= _pinl_975_iv=[_pinl_981__eat_24] < [ N__SSA0_2 ] genwidth [ _wlsimp_1158 ])
{
_ivexi_2036_ext = _noteminval_( _pinl_981__eat_24, _uprf_1209);
_ivexi_2037_ext = _notemaxval_( _ivexi_2036_ext, N__SSA0_2);
_dup_2038__uprf_1203 = _sub_SxS_( _ivexi_2037_ext, _uprf_1209);
_dup_2041__uprf_1190, _dup_2042__uprf_1191 = _val_lt_val_SxS_( _dup_2038__uprf_1203, N__SSA0_2);
_dup_2046__pinl_977__flat_12 = _afterguard_( _dup_2041__uprf_1190, _dup_2042__uprf_1191);
} : _dup_2046__pinl_977__flat_12 ;
} :
genarray( [ N__SSA0_2 ], _flat_21);
What I find odd about this is that there is clearly a complete partitioning
of the array in the next two partitions, which clearly cover the
genarray.
I would like it if we can prevent such degenerate partitions
from being generated at all, or provide a way to eliminate them
when they are clearly degenerate, as this one is.
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18059 linux-gnu_x86_64
(Tue Feb 26 10:58:59 EST 2013 by sac)
This may require a change in the semantics of WLs, but I think
it would be a good thing. I am not convinced that the current
semantics serve any useful purpose, in practice.
If you compile this way, you can observe the fault:
sac2c -doawlf -nowlf -v1 crud4.sac -bopt >crud
Adding -DAKV eliminates the problem (by using a constant shift count),
and lets AWLF work as it should.</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1146blife.sac could do better than it does2017-11-19T20:24:49ZRobert Berneckyblife.sac could do better than it does| | |
| --- | --- |
| Bugzilla Link | [1047](http://bugs.sac-home.org/show_bug.cgi?id=1047) |
| Created on | Feb 24, 2013 20:19 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I was just looking ...| | |
| --- | --- |
| Bugzilla Link | [1047](http://bugs.sac-home.org/show_bug.cgi?id=1047) |
| Created on | Feb 24, 2013 20:19 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I was just looking at bug725.sac, an incarnation of Conway's Game of Life,
It does this, in function addpad():
sh1 = shape(a);
pad1 = [genarray([sh1[1]],0)];
add1 = pad1 ++ a ++ pad1;
The ++ functions are unable to AWLF, because of the way that pad1
is defined.
If the code is rewritten this way:
sh1 = shape(a);
shpad = [ 1, sh1[1]];
pad1 = genarray(shpad,0);
add1 = pad1 ++ a ++ pad1;
then the whole shebang wolds into a single WL. I think I'll go
change blife.sac to work this way. However, it would not
be a lot of work for some keener to make AWLF work on the original
blife.sac code.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1207DL anti-strength reduction causes opt failure in AWLF unit test relaxAKD.sac2017-11-19T20:30:19ZRobert BerneckyDL anti-strength reduction causes opt failure in AWLF unit test relaxAKD.sac| | |
| --- | --- |
| Bugzilla Link | [1046](http://bugs.sac-home.org/show_bug.cgi?id=1046) |
| Created on | Feb 24, 2013 16:00 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [StdlibCatenateAxis1AKD.sac](/uplo...| | |
| --- | --- |
| Bugzilla Link | [1046](http://bugs.sac-home.org/show_bug.cgi?id=1046) |
| Created on | Feb 24, 2013 16:00 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [StdlibCatenateAxis1AKD.sac](/uploads/cfa7cfda03f57ef53c35aa1e1e8db0c2/StdlibCatenateAxis1AKD.sac), [bugdl.sac](/uploads/ac948c300a5a31bd1ef2c7df3b437373/bugdl.sac), [bugdl2.sac](/uploads/4d408d79ea722149ea0df45234ec34af/bugdl2.sac), [crud.sac](/uploads/6f72af3588391460c68ba86b89e4b7d8/crud.sac), [xStdlibCatenateAxis1AKD.sac](/uploads/af3ac99e8c32fdeff1a14dddf618235e/xStdlibCatenateAxis1AKD.sac), [bug1046D.sac](/uploads/1689c2ce80bf4c96f46547e0f64b5579/bug1046D.sac) |
## Extended Description
<pre>Created an attachment (id=944)
source code to reproduce fault
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
product rev 18058 linux-gnu_x86_64
(Thu Feb 21 14:45:15 EST 2013 by sac)
sac2c bugdl.sac -doawlf -nowlf -v1 -bopt >crud
Ditto the other attachments...
The problem is that DL takes an expression such as:
X = id( 2);
Z = ( X + X) - X;
and turns it into:
Z = ( 2 * X) - X;
at which point, it is unable to simplify the expression
tree any more. Which is dull.
This causes AWLF intersect calculation to fail, which means that
sum(cat(A,B)) fails to WL fold.
Clemens: Please let me know your schedule for repairing this. If
it going to take you months, as opposed to a day or two, to fix it,
I'll just go and (probably) disable the add->mul strength anti-reduction code
until such time as you can find time to fix it to your liking.</pre>Clemens GrelckClemens Grelckhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1145EWL doesn't like empty array WLs2017-11-19T20:24:47ZRobert BerneckyEWL doesn't like empty array WLs| | |
| --- | --- |
| Bugzilla Link | [1043](http://bugs.sac-home.org/show_bug.cgi?id=1043) |
| Created on | Jan 12, 2013 15:29 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>sac2c bug.sac
...
*...| | |
| --- | --- |
| Bugzilla Link | [1043](http://bugs.sac-home.org/show_bug.cgi?id=1043) |
| Created on | Jan 12, 2013 15:29 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>sac2c bug.sac
...
** 10: Enhancing with-loops ...
**** Introducing explicit accumulators ...
**** Adding default partitions ...
**** Applying constant folding ...
**** Applying common subexpression elimination ...
**** Generating full with-loop partitions ...
OOOOOOOPS, your program crashed the compiler 8-((
cat bug.sac
use Array:all;
int main()
{
x = [:int];
z = with {
( [0] <= iv < _shape_A_( x)) : 42;
} : modarray(x);
StdIO::print(z);
return(0);
}
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18051 linux-gnu_x86_64
(Fri Jan 11 18:14:26 EST 2013 by sac)
I ran into this while trying to fault-isolate a bug that
shows up in CF, apparently due to WLUR ending up in the
same situation as above.
I'll leave this for someone in Edinburgh to fix.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1144_mod_() definition blocks AWLF from operating on rotate() for AKD arrays2017-11-19T20:24:44ZRobert Bernecky_mod_() definition blocks AWLF from operating on rotate() for AKD arrays| | |
| --- | --- |
| Bugzilla Link | [1042](http://bugs.sac-home.org/show_bug.cgi?id=1042) |
| Created on | Jan 09, 2013 15:16 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I have been looking...| | |
| --- | --- |
| Bugzilla Link | [1042](http://bugs.sac-home.org/show_bug.cgi?id=1042) |
| Created on | Jan 09, 2013 15:16 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I have been looking at the SAC stdlib rotate (and shift)
functions, as they relate to AWLF, and this led me to
look at the definition of the _mod_()
primitive in SAC. I find it wanting, for several reasons.
The underlying challenge is to make AWLF/WLF operate
with rotate as a producer WL and as a consumer WL.
The existing stdlib code uses mod() and a conditional
to normalize the rotate count. I.e., map it
into a non-negative integer
in the range 0...(N-1), where N is the length of
the rotation axis. In the common cases
where the rotate count is a constant, this is not
a problem. However, in APL code, we often see
expressions such as this one, to drop the leading
blanks from a text vector:
((vec≠' ')⍳1) ↓ vec
or
((vec≠' ')⍳1) ⌽ vec
I do not know what the design rationale was for the mod()
primitive, but suspect it was intended to mimic the
behavior of the (equally ill-defined) a%b (remainder)
operation in C.
1. According to the C99 standard*, the result is defined only
if "...the quotient a/b is representable". E.g.,
0%0 is undefined.
For rotate() arguments where the rotate count ends up being
zero, this can cause the normalization of the rotate count
to signal an error.
In APL, where considerable thought was
given to the definition of residue (aka remainder) on
all integers, floats, and complex numbers,
0 | 0 ( 0%0 in C) is defined to produce 0.
2. In K&R (2nd Edition), "the sign of the result for
% {is} machine-dependent for negative operands."
By constrast, in APL, the definition is clearly specified for
all integer (and, in fact, all numeric) arguments. NB.
argument order is reversed in SAC from that of APL:
¯5 ¯4 ¯3 ¯2 ¯1 0 1 2 3 4 NB. A
0 1 2 3 4 0 1 2 3 4 NB. 5|A (AKA A%5)
This is not the same as the current behavior of the SAC
mod() primitive on negative A:
-5 -4 -3 -2 -1 0 1 2 3 4 NB. A
-5 -4 -3 -2 -1 0 1 2 3 4 NB. A%5
Note that the APL definition maps a negative
rotate count into the correct non-negative count.
The SAC behavior requires checking for a negative
count and then adding b to the count for negatives.
This often inhibits the ability to perform AWLF on
rotated arguments/results, because of problems
around partition/index vector intersect calculation.
Furthermore, it may be that the SAC definition is
"implementation-dependent", in which case we are
left in a position of not being able even to specify the
behavior of the stdlib rotate() function. It could screw
anyone running on an implementation (e.g., Windows?) that produces
different results.
If we are going to define stdlib functions on SAC primitives,
then we need to define the precise semantics of those
primitives, and eschew "implementation-dependent"
behavior.
So, a few questions,and a few proposals for redefinition:
Q1: Does anybody depend on the result of SAC
mod() on negative or zero arguments?
Q2: Are there concrete objections to extending the definition
of SAC mod() to handle zeros and negative arguments
in the same way that APL does, thereby avoiding
any arguments about "implementation-defined"
behavior there and in the stdlib?
P0: If the answers to Q1 and Q2 are No, I propose to
change sac2c mod() to operate as APL does, and
to change the stdlib rotate() functions to rely on
that definition.
2013-01-09: I have not heard any response from sacdev or others
on this topic. Silence is consent, in my book, so I am going
to proceed with the above implementation, as proposed.
* This is a draft of same:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1143Another nail in the coffin for CTZ2017-11-19T20:24:40ZRobert BerneckyAnother nail in the coffin for CTZ| | |
| --- | --- |
| Bugzilla Link | [1040](http://bugs.sac-home.org/show_bug.cgi?id=1040) |
| Created on | Dec 17, 2012 18:59 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [SCSprf_mod.sac](/uploads/e87f8068...| | |
| --- | --- |
| Bugzilla Link | [1040](http://bugs.sac-home.org/show_bug.cgi?id=1040) |
| Created on | Dec 17, 2012 18:59 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [SCSprf_mod.sac](/uploads/e87f8068c93be4e57ffc82677d4770b4/SCSprf_mod.sac) |
## Extended Description
<pre>Created an attachment (id=942)
source code to reproduce fault
The attached CF unit test fails if you compile it this way, in that
the _gt_() is not optimized out:
cd ~/sac/testsuite/optimizations/constantfolding
sac2c SCSprf_mod.sac -doawlf -nowlf -v1 -bopt:uglf >crud
If you compile it adding -noctz, the relational does get
optimized away.
Unfortunately, disabling CTZ cripples some important AWLF
benchmarks, so we need to come up with something better than CTZ.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1142AWLF unit test relaxAKD.sac fails - can't analyze _le_VxS( constant, val w/ma...2017-11-19T20:24:36ZRobert BerneckyAWLF unit test relaxAKD.sac fails - can't analyze _le_VxS( constant, val w/maxval)| | |
| --- | --- |
| Bugzilla Link | [1039](http://bugs.sac-home.org/show_bug.cgi?id=1039) |
| Created on | Dec 14, 2012 20:48 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [relaxAKDnotake.sac](/uploads/eaef...| | |
| --- | --- |
| Bugzilla Link | [1039](http://bugs.sac-home.org/show_bug.cgi?id=1039) |
| Created on | Dec 14, 2012 20:48 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [relaxAKDnotake.sac](/uploads/eaefbd888d648f6811f059e6181621b8/relaxAKDnotake.sac) |
## Extended Description
<pre>Created an attachment (id=941)
source code to reproduce fault
An AKD version of Bodo's function relax() from his "Condensing..." paper
does not AWLF. The attached much-simplified version
(basically, drop(i, drop( j, X)) does not fold either.
The immediate problem is that the predicate, WLINTERSECTION1PART, can not
be computed from this relational:
p = _le_VxS_( constant, valueWithMaxval);
Cf can handle values with extrema, and it can handle constants,
but not both at once. I started to extend CF to make it do this,
but it occurred to me that PRFUNR would likely do the trick.
And, indeed, it does, so I am going to extend PRFUNR to unroll
VxS, SxV and VxV relationals. If that proves catastrophic for
some reason, I'll do the dirty work in CF.
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18040 linux-gnu_x86_64
(Fri Dec 14 15:32:12 EST 2012 by sac)
sac2c -v1 relaxAKDnotake.sac -doawlf -nowlf -bopt >crud</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1141Potential value guard optimization2017-11-19T20:24:33ZRobert BerneckyPotential value guard optimization| | |
| --- | --- |
| Bugzilla Link | [1038](http://bugs.sac-home.org/show_bug.cgi?id=1038) |
| Created on | Dec 10, 2012 21:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Here is a problem t...| | |
| --- | --- |
| Bugzilla Link | [1038](http://bugs.sac-home.org/show_bug.cgi?id=1038) |
| Created on | Dec 10, 2012 21:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Here is a problem that has been with us since guards were introduced.
Consider this expression, used to guard against upper bound index errors
in sel() code:
y = m - 1;
x', p = _val_lt_val_SxS_( x, y);
AVIS_MAX( x) = 1 + (m - 2);
CF could check for AVIS_MAX(x) == y and simplify
this particular case. However, in general, we may have
AVIS_MAX( x) = 1 + ( m -3), so the CF change would not
help.
At first glance, it seems that what we want is
something along the lines of CTZ,
where we would subtract x (or y) from both arguments of the guard.
This, however, would cause AWLFI backtrace of index vectors from the sel()
to the WITHID_VEC to fail, so that idea is out of the picture.
A more likely approach, it seems to me, is to include an extra
argument in most/all guards, and put the computation there, as
a predicate, e.g.,:
pred = ( x - y) < 0;
x', p = _val_lt_val_SxS_( x, y, pred);
If CF (or some other traversal) determines that pred is true,
then the guard can be removed. If pred is false, then we raise an
index error. Otherwise, we really do not know at compile time
whether the index is valid or not, so a post-optimization path
merely removes the pred argument, and we're back to the situation
as it is today.
I stumbled onto this while looking at AWLF unit test relaxAKDnotake.sac,
compiled with -doawlf -nowlf.
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18038 linux-gnu_x86_64
(Sun Dec 9 16:58:31 EST 2012 by sac)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1242AWLF unit test failure with rotate2017-11-19T20:33:08ZRobert BerneckyAWLF unit test failure with rotate| | |
| --- | --- |
| Bugzilla Link | [1036](http://bugs.sac-home.org/show_bug.cgi?id=1036) |
| Created on | Nov 18, 2012 18:07 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud3.sac](/uploads/7889a64e94b93...| | |
| --- | --- |
| Bugzilla Link | [1036](http://bugs.sac-home.org/show_bug.cgi?id=1036) |
| Created on | Nov 18, 2012 18:07 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud3.sac](/uploads/7889a64e94b9303b12760ba4b7a02eb7/crud3.sac) |
## Extended Description
<pre>Created an attachment (id=939)
source code to reproduce fault
AWLF was working, but stopped working some time around/after July, on
some cases where (I think) the consumer WL is using a subtraction
on its index vector. The immediate failure is inability to compute
the predicate WLINTERSECTION1PART.
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18028 linux-gnu_x86_64
(Thu Nov 15 16:04:14 EST 2012 by sac)
sac2c crud3.sac -doawlf -nowlf -v1 -bopt:uglf >crud</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1140apex UTBaseValue.sac test fails at end of -bopt. IVE suspected2017-11-19T20:24:30ZRobert Berneckyapex UTBaseValue.sac test fails at end of -bopt. IVE suspected| | |
| --- | --- |
| Bugzilla Link | [1035](http://bugs.sac-home.org/show_bug.cgi?id=1035) |
| Created on | Nov 16, 2012 14:27 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/f6a1b8a6d0d2a0...| | |
| --- | --- |
| Bugzilla Link | [1035](http://bugs.sac-home.org/show_bug.cgi?id=1035) |
| Created on | Nov 16, 2012 14:27 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/f6a1b8a6d0d2a0f0c869ee45045af8f1/crud.sac) |
## Extended Description
<pre>Created an attachment (id=938)
source code to reproduce fault
**** Eliminating symbolic array attributes ...
**** Applying type upgrade ...
constants/constants_struc_ops.c:1095 Assertion "cviv[0] < cvshp[0]" failed!
Index error: iv[0] >= shp([0]
The exact problem is that iv and shp have the same value in COvect2Offset,
which indeed indicates Index error.
apex@rattler:~/apex3/benchmks/UTBaseValue$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18028 linux-gnu_x86_64
(Thu Nov 15 16:04:14 EST 2012 by sac)
apex@rattler:~/apex3/benchmks/UTBaseValue$ sac2c crud.sac -v4</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1241rle.sac failure: LACSO vs. DCR causes crash in WLIR2017-11-19T20:33:04ZRobert Berneckyrle.sac failure: LACSO vs. DCR causes crash in WLIR| | |
| --- | --- |
| Bugzilla Link | [1034](http://bugs.sac-home.org/show_bug.cgi?id=1034) |
| Created on | Nov 08, 2012 23:05 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.breaks.sac](/uploads/64beb41...| | |
| --- | --- |
| Bugzilla Link | [1034](http://bugs.sac-home.org/show_bug.cgi?id=1034) |
| Created on | Nov 08, 2012 23:05 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.breaks.sac](/uploads/64beb41c52528b84bbd678a69c225ad0/crud.breaks.sac) |
## Extended Description
<pre>cd sac/apex/rle
sac@rattler:~/sac/apex/rle$ sac2c rle.sac -v1
stdopt/withloop_invariant_removal.c:861 Assertion "AVIS_DEFDEPTH(ID_AVIS(arg_node)) != DD_UNDEFINED" failed!
reference to undefined identifier _lacso_17413
sac@rattler:~/sac/apex/rle$ sac2c rle.sac -v1 -nolacso
sac2c -V
sac@rattler:~/sac/apex/rle$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18019 linux-gnu_x86_64
(Thu Nov 8 17:08:16 EST 2012 by sac)
I believe what is going on is this:
1. LACSO introduces a new scalar result value, which
is never used in the calling context, but it IS used
as an AVIS_SHAPE element in the called context.
2. DCR comes along, sees that the result value is unused in
the caller, so deletes the N_funcond after the recursive
call, which then marks the recursive call result dead.
3. Things eventually die in WLIR.
I think the correct fix is to make DCR check for
uses of the result value in AVIS son nodes, and mark
the avis as live if that is the case. I don't like this
approach, but have no better ideas yet.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1139Nested array design problems and bugs2017-11-19T20:24:26ZRobert BerneckyNested array design problems and bugs| | |
| --- | --- |
| Bugzilla Link | [1030](http://bugs.sac-home.org/show_bug.cgi?id=1030) |
| Created on | Oct 09, 2012 15:46 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [convonEach.sac](/uploads/76847da0...| | |
| --- | --- |
| Bugzilla Link | [1030](http://bugs.sac-home.org/show_bug.cgi?id=1030) |
| Created on | Oct 09, 2012 15:46 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [convonEach.sac](/uploads/76847da05e240c3a2e42a2d36908ef0c/convonEach.sac) |
## Extended Description
<pre>Created an attachment (id=936)
source code to reproduce fault
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18245:MODIFIED linux-gnu_x86_64
(Mon Oct 8 15:37:33 EDT 2012 by sac)
The nested array code has a number of distinct problems:
1. The generated code does not use _type_conv for enclose and
disclose. Instead, it uses new primitives:
sac2c convonEach.sac -O3 -v1 -wls_aggressive -doawlf -nowlf -bopt >crud.awlf
_pinl_8311_result = _enclose_( double[.], hidden(11), _pinl_8320__icc_3577);
_pinl_8223_result = _disclose_( hidden(11), double[.], _pinl_8311_result);
Bodo expressed a preference for use of _type_conv() here. I am not
sure of his exact reasoning, so perhaps he can expand this comment with
his rationale.
2. The type of _pinl_8311_result is "hidden(11)". I do not know what
this means. Can someone please provide appropriate documentation for
same, so that we can make CF and other optimizations work on
nested arrays?
3. This is a more fundamental design problem: All AVIS son information
about the _enclose_() argument is lost in its result, from what I
can see.
This means that AWLF and even WLF are unable to operate on disclosed
array elements, resulting in dismal performance.
Consider the convolution example in convonEach.sac: It is effectively
doing:
matmul( filter, take(shape(filter), drop(k, trace)));
In order to perform WLF, it at least needs to know the shape of trace
(the disclosed signal vector). This information has been lost.
In this degenerate case of enclose/disclose, once (1) and (2) have
been solved, then CF should be able to eliminate the enclose/disclose
pair, which would solve this particular problem.
However, consider the more general case of something like:
traces = ( enclose( trace0) ++ enclose( trace1) ++ enclose(trace2)...);
z = matmulEach( (enclose( filter), traces);
We now have no guarantee that the shapes of the traces are the same.
Worse yet, in the generalvector-matrix multiply case, we need to
know only that shape(filter)== take(1, shape(trace)) for all traces.
As a result of the absence of vital information for WLF/WLF to operate,
performance of the convonEach benchmark is dismal: roughly 130sec,
versus less than 1sec for the non-enclosed version.
What this tells me is that we need to rethink the whole idea of invariant
properties, in the light of nested arrays, and how we can apply optimizations
on such arrays.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1240LACS unit test bugipbb.sac produces very different results, depending on sac2...2017-11-19T20:33:01ZRobert BerneckyLACS unit test bugipbb.sac produces very different results, depending on sac2c options| | |
| --- | --- |
| Bugzilla Link | [1028](http://bugs.sac-home.org/show_bug.cgi?id=1028) |
| Created on | Oct 03, 2012 16:37 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bugipbb.sac](/uploads/d45259943a9...| | |
| --- | --- |
| Bugzilla Link | [1028](http://bugs.sac-home.org/show_bug.cgi?id=1028) |
| Created on | Oct 03, 2012 16:37 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bugipbb.sac](/uploads/d45259943a90f5ba6e740625bd6869d8/bugipbb.sac) |
## Extended Description
<pre>Created an attachment (id=933)
source code to reproduce fault
After attempting to repair Bug #1027, I ran the LACS unit test bugipbb.sac
and got an odd completion code. So, I tried to isolate the fault.
Here are my findings thus far:
sac2c bugipbb.sac -v1
sac@rattler:~/sac/testsuite/optimizations/lacs$ a.out; echo $?
192
sac@rattler:~/sac/testsuite/optimizations/lacs$ sac2c bugipbb.sac -v1 -noopt
WARNING: With-Loop unrolling (WLUR) was disabled using the command line.
WARNING: However, unrolling of single-trip with-loops is required for code
WARNING: generation. Therefore, WLUR will be re-enabled with the maximum
WARNING: number of unrolling steps set to 1.
wltransform/wltransform.c:7138 Assertion "FALSE" failed!
with-loop with empty iteration space found!
sac@rattler:~/sac/testsuite/optimizations/lacs$ sac2c bugipbb.sac -v1 -nols
sac@rattler:~/sac/testsuite/optimizations/lacs$ a.out; echo $?
248
sac@rattler:~/sac/testsuite/optimizations/lacs$ sac2c bugipbb.sac -v1 -nols -nocf
sac@rattler:~/sac/testsuite/optimizations/lacs$ a.out; echo $?
208
sac@rattler:~/sac/testsuite/optimizations/lacs$ sac2c bugipbb.sac -v1 -nocf
sac@rattler:~/sac/testsuite/optimizations/lacs$ a.out; echo $?
208
sac@rattler:~/sac/testsuite/optimizations/lacs$ sac2c bugipbb.sac -v1
sac@rattler:~/sac/testsuite/optimizations/lacs$ a.out; echo $?
192
sac@rattler:~/sac/testsuite/optimizations/lacs$ sac2c bugipbb.sac -v1 -dolacsi
sac@rattler:~/sac/testsuite/optimizations/lacs$ a.out; echo $?
192
sac@rattler:~/sac/testsuite/optimizations/lacs$ sac2c bugipbb.sac -v1 -dolacsi -dolacso
sac@rattler:~/sac/testsuite/optimizations/lacs$ a.out; echo $?
192
sac@rattler:~/sac/testsuite/optimizations/lacs$ sac2c bugipbb.sac -v1 -dolacsi -dolacso -nols
sac@rattler:~/sac/testsuite/optimizations/lacs$ a.out; echo $?
248
sac@rattler:~/sac/testsuite/optimizations/lacs$ sac2c bugipbb.sac -v1 -dolacsi -dolacso -nols -nocyc
stdopt/withloop_invariant_removal.c:861 Assertion "AVIS_DEFDEPTH(ID_AVIS(arg_node)) != DD_UNDEFINED" failed!
reference to undefined identifier _lacso_3074
The last crash is certainly my doing. Not sure about the others.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1138First nested array bug: modarray does not work on nested arrays2017-11-19T20:24:23ZRobert BerneckyFirst nested array bug: modarray does not work on nested arrays| | |
| --- | --- |
| Bugzilla Link | [1025](http://bugs.sac-home.org/show_bug.cgi?id=1025) |
| Created on | Oct 01, 2012 21:05 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>sac2c -V
sac2c v1.0...| | |
| --- | --- |
| Bugzilla Link | [1025](http://bugs.sac-home.org/show_bug.cgi?id=1025) |
| Created on | Oct 01, 2012 21:05 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18236:MODIFIED linux-gnu_x86_64
(Mon Oct 1 11:57:46 EDT 2012 by sac)
This simple example of nested array code fails, due to TC not
liking non-simple array arguments:
cat crud2.sac
/*
* Simple example of nested array use in sac2c:
* Construct (iota(3), iota(4), iota(5)...).
*
*/
use Array:all;
nested int[.] vec;
int main()
{
hole = enclose_vec ( [42] );
x = 3 + iota(10);
z = [ hole, hole, hole, hole, hole, hole, hole, hole, hole, hole];
for( i=0; i<20; i++ ) {
z = _modarray_AxVxS_( z, [i], enclose_vec( iota( x[i])));
}
StdIO::print(z);
return(0);
}
The problem is that NTCCTprf_modarray_AxVxS calls TEassureSameSimpleType,
which wants, oddly enough, a SimpleType. Which z is not.
Question for Dr. TC: Can we simply relax that test (handwave, handwave)
to a make it a call to the (non-existent) TCassureSameType?
Or is the pit deeper than that?</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1137Catch-22: LIR won't lift2017-11-19T20:24:19ZRobert BerneckyCatch-22: LIR won't lift| | |
| --- | --- |
| Bugzilla Link | [1022](http://bugs.sac-home.org/show_bug.cgi?id=1022) |
| Created on | Sep 11, 2012 22:32 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I just traced an AW...| | |
| --- | --- |
| Bugzilla Link | [1022](http://bugs.sac-home.org/show_bug.cgi?id=1022) |
| Created on | Sep 11, 2012 22:32 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I just traced an AWLF failure partway back to this loopfun code:
int loopfun( int _lacs_2325) {
...
_uprf_1573, _uprf_1574 = _non_neg_val_S_( _lacs_2325);
loopfun( _uprf_1573);
There are two distinct problems here:
a. LACS won't propagate AVIS_MINVAL( _lacs_2325) = 0 into the loopfun,
because the variable is not loop-invariant.
b. DLIR won't lift the guard expression out of the loopfun, for the
same reason, I think.
As I write this, I realize that, in this particular case, I may
be able to resolve the issue this enhancement to LACS:
In the calling environment, _lacs_2325 has AVIS_MINVAL = 0;
In the recursive call, _uprf_1573 has AVIS_MINVAL = 0.
In that case, LACS can happily set AVIS_MINVAL( _lacs_2325) = 0,
and the code should get better.
However, I suspect this is not the case in general, so welcome
ideas on better ways to tackle this problem.
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18218:MODIFIED linux-gnu_x86_64
(Tue Sep 11 16:07:19 EDT 2012 by sac)
cd ~/sac/testsuite/optimizations/lacs$
sac2c simpleLoopAKD.sac -bopt:saacyc:lof:5 -doawlf -nowlf -v1 -#d,LIR,WLIR,DLIR &> crud</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1136type checker reports wrong parameter count2017-11-19T20:24:15ZRobert Berneckytype checker reports wrong parameter count| | |
| --- | --- |
| Bugzilla Link | [1021](http://bugs.sac-home.org/show_bug.cgi?id=1021) |
| Created on | Sep 10, 2012 21:02 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>ABORT: line 12 fil...| | |
| --- | --- |
| Bugzilla Link | [1021](http://bugs.sac-home.org/show_bug.cgi?id=1021) |
| Created on | Sep 10, 2012 21:02 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>ABORT: line 12 file: parserbug.sac
ABORT: No definition found for a function "StdIO::print" that accepts an
ABORT: argument of type "int{0}" as parameter no 3. Full argument types are
ABORT: "( Terminal::Terminal, TermFile::TermFile, int{0}, int{20})".
*** Compilation failed ***
*** Exit code 44 (Running type inference system)
*** 1 Error(s), 0 Warning(s)
sac@rattler:~/sac/testsuite/optimizations/lacs$ cat parserbug.sac
/*
* Wrong element number for error message.
*
*/
use Array:{*,--,-,genarray,iota,sum,+,take,++,<};
int main()
{
i = 0;
lim = 20;
StdIO::print( i, lim);
return( 0);
}
sac@rattler:~/sac/testsuite/optimizations/lacs$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18218:MODIFIED linux-gnu_x86_64
(Mon Sep 10 13:25:23 EDT 2012 by sac)</pre>BugZillaBugZilla