sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T20:23:29Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1122LS does not maintain global optimization counter2017-11-19T20:23:29ZRobert BerneckyLS does not maintain global optimization counter| | |
| --- | --- |
| Bugzilla Link | [985](http://bugs.sac-home.org/show_bug.cgi?id=985) |
| Created on | Jun 20, 2012 19:46 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
I just noticed this now.
I...| | |
| --- | --- |
| Bugzilla Link | [985](http://bugs.sac-home.org/show_bug.cgi?id=985) |
| Created on | Jun 20, 2012 19:46 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
I just noticed this now.
I do not plan to fix it, as I am in the process of replacing LS
by LACS.BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1121buildvAKD.sac compiles very slow, due to garbage introduced into AST during m...2017-11-19T20:23:26ZRobert BerneckybuildvAKD.sac compiles very slow, due to garbage introduced into AST during microcycle| | |
| --- | --- |
| Bugzilla Link | [979](http://bugs.sac-home.org/show_bug.cgi?id=979) |
| Created on | Jun 18, 2012 18:41 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [buildvAKD.sac](/uploads/76401133f17...| | |
| --- | --- |
| Bugzilla Link | [979](http://bugs.sac-home.org/show_bug.cgi?id=979) |
| Created on | Jun 18, 2012 18:41 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [buildvAKD.sac](/uploads/76401133f174de47b6919522781ce8dd/buildvAKD.sac) |
## Extended Description
<pre>Created an attachment (id=902)
source code to reproduce fault
As of the latest ( 17920:MODIFIED) update, this
takes a LONG time to compile:
cd apex/buildvAKD
sac2c buildvAKD.sac -doawlf -nowlf -#d,SSE
If you look at the SSE output, you'll see that WLIR and
CSE keep doing the same thing over and over again
in the AWLFI micro-cycle, OR else some other optimization
is introducing garbage that they run into repeatedly.
Here is a sample:
SimplifySymb: SSE: Cycle interation 14: running UESD
SimplifySymb: SSE: Cycle interation 14: running DCR
SimplifySymb: SSE: DLIR= 0, WLIR= 3, INL=0, CSE=2360, TUP=0, CF=0, VP=0, AS=0, AL=0, DL=0
SimplifySymb: SSE: Cycle interation 15 (fun function _dup_7892_buildvXID__Loop_1) begins.
SimplifySymb: SSE: Cycle interation 15: running DLIR
SimplifySymb: SSE: Cycle interation 15: running WLIR
SimplifySymb: SSE: Cycle interation 15: running INL
SimplifySymb: SSE: Cycle interation 15: running ISAA
SimplifySymb: SSE: Cycle interation 15: running CSE
SimplifySymb: SSE: Cycle interation 15: running NTC
SimplifySymb: SSE: Cycle interation 15: running EAT
SimplifySymb: SSE: Cycle interation 15: running EBT
SimplifySymb: SSE: Cycle interation 15: running DFC
SimplifySymb: SSE: Cycle interation 15: running CF
SimplifySymb: SSE: Cycle interation 15: running VP
SimplifySymb: SSE: Cycle interation 15: running ESD
SimplifySymb: SSE: Cycle interation 15: running AS
SimplifySymb: SSE: Cycle interation 15: running CF
SimplifySymb: SSE: Cycle interation 15: running CSE
SimplifySymb: SSE: Cycle interation 15: running AL
SimplifySymb: SSE: Cycle interation 15: running DL
SimplifySymb: SSE: Cycle interation 15: running UESD
SimplifySymb: SSE: Cycle interation 15: running DCR
SimplifySymb: SSE: DLIR= 0, WLIR= 3, INL=0, CSE=2428, TUP=0, CF=0, VP=0, AS=0, AL=0, DL=0
SimplifySymb: SSE: Cycle interation 16 (fun function _dup_7892_buildvXID__Loop_1) begins.
SimplifySymb: SSE: Cycle interation 16: running DLIR
I think this is new since the DevCamp started, so hope</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1120apex UTCompress unit test dies in -bopt:cyc:wls:1 if -dowlsimp2017-11-19T20:23:21ZRobert Berneckyapex UTCompress unit test dies in -bopt:cyc:wls:1 if -dowlsimp| | |
| --- | --- |
| Bugzilla Link | [975](http://bugs.sac-home.org/show_bug.cgi?id=975) |
| Created on | Jun 07, 2012 21:13 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTCompress.sac](/uploads/c2fd69366e...| | |
| --- | --- |
| Bugzilla Link | [975](http://bugs.sac-home.org/show_bug.cgi?id=975) |
| Created on | Jun 07, 2012 21:13 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTCompress.sac](/uploads/c2fd69366e320f192774632f9ace36b6/UTCompress.sac) |
## Extended Description
<pre>Created an attachment (id=898)
source code to reproduce fault
This fails in Build #17873, but likely has been around for a while.
sac2c UTCompress.sac -noctzg -noedfa -nopetl -v4 -noal -nolur -nodlir -nocwle -nowlir -v1 -bopt:cyc:wls:1 >crudtree/traverse.c:67 Assertion "arg_node" failed!
OOOOOOOPS: TRAVdo() called with a NULL node!
The immediate cause of the crash is that WITH_PART is NULL.
Now, we disable WLSIMP and try again:
apex@rattler:~/apex3/benchmks/UTCompress$ sac2c UTCompress.sac -noctzg -noedfa -nopetl -v4 -noal -nolur -nodlir -nocwle -nowlir -v1 -bopt:cyc:wls:1 -nowlsimp >crud
Compiling with -d treecheck -chkfreq 4 did not provide me with any
more enlightenment.
The failure occurs in the first pass of CYC, I am not sure where to point
fingers on this one.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1119apex benchmark crc2AKD.sac runs out of memory2017-11-19T20:23:17ZRobert Berneckyapex benchmark crc2AKD.sac runs out of memory| | |
| --- | --- |
| Bugzilla Link | [974](http://bugs.sac-home.org/show_bug.cgi?id=974) |
| Created on | Jun 07, 2012 19:29 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crc2AKD.sac](/uploads/53dcbe3be23c5...| | |
| --- | --- |
| Bugzilla Link | [974](http://bugs.sac-home.org/show_bug.cgi?id=974) |
| Created on | Jun 07, 2012 19:29 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crc2AKD.sac](/uploads/53dcbe3be23c570bab0b962c012ba11c/crc2AKD.sac) |
## Extended Description
<pre>Created an attachment (id=897)
source code to reproduce fault
This one has been with us for a while (months or more)
I see several problems here:
sac2c -doawlf -nowlf -v4 crc2AKD.sac -#d,SSE,CSE &> crud
1. After we get into SSACYC, and AWLFI, we enter a micro-cycle
in AWLFI, which has this debug output:
CSEfundef: CSE: leaving (fundef) table32XBB
SimplifySymb: SSE: Cycle interation 17: running AL
SimplifySymb: SSE: Cycle interation 17: running DL
SimplifySymb: SSE: Cycle interation 17: running UESD
SimplifySymb: SSE: Cycle interation 17: running DCR
SimplifySymb: SSE: DLIR= 0, WLIR= 0, INL=0, CSE=25, TUP=0, CF=0, VP=0, AS=0, AL=0, DL=0
SimplifySymb: SSE: Cycle interation 18 (fun function table32XBB) begins.
SimplifySymb: SSE: Cycle interation 18: running DLIR
SimplifySymb: SSE: Cycle interation 18: running WLIR
SimplifySymb: SSE: Cycle interation 18: running INL
SimplifySymb: SSE: Cycle interation 18: running ISAA
SimplifySymb: SSE: Cycle interation 18: running CSE
and then, this:
CSEfundef: CSE: leaving (fundef) table32XBB
SimplifySymb: SSE: Cycle interation 18: running AL
SimplifySymb: SSE: Cycle interation 18: running DL
SimplifySymb: SSE: Cycle interation 18: running UESD
SimplifySymb: SSE: Cycle interation 18: running DCR
SimplifySymb: SSE: DLIR= 0, WLIR= 0, INL=0, CSE=25, TUP=0, CF=0, VP=0, AS=0, AL=0, DL=0
SimplifySymb: SSE: Cycle interation 19 (fun function table32XBB) begins.
SimplifySymb: SSE: Cycle interation 19: running DLIR
SimplifySymb: SSE: Cycle interation 19: running WLIR
SimplifySymb: SSE: Cycle interation 19: running INL
SimplifySymb: SSE: Cycle interation 19: running ISAA
SimplifySymb: SSE: Cycle interation 19: running CSE
Note that CSE keeps doing 25 "optimizations", but none of the other
ops claim to have done anything. However, CSE does remove
(different names each time) ESD-generated variables, e.g,.
SetSubstAttr: CSE: substitute ids _esd_117587 with _esd_113978
CSElet: CSE: Common subexpression eliminated for _esd_117587 in line 136
Perhaps the opts in SimplifySymbioticExpression are
poorly chosen, or perhaps their ordering is bad. Here it is, from AWLFI.
Not my macro...
RUNOPT(DLIR, global.optimize.dodlir, countDLIR = global.optcounters.dlir_expr, DLIRdoLoopInvariantRemoval);
RUNOPT(WLIR, global.optimize.dowlir, countWLIR = global.optcounters.wlir_expr, WLIRdoLoopInvariantRemoval);
RUNOPT(INL, global.optimize.doinl, countINL = global.optcounters.inl_fun, INLdoInlining);
RUNOPT(ISAA, global.optimize.dosaa, , ISAAdoInsertShapeVariables);
RUNOPT(CSE, global.optimize.docse, countCSE = global.optcounters.cse_expr, CSEdoCommonSubexpressionElimination);
RUNOPT(NTC, global.optimize.dotup, countTUP = global.optcounters.tup_upgrades, NTCdoNewTypeCheck);
RUNOPT(EAT, global.optimize.dotup, , EATdoEliminateAlphaTypes);
RUNOPT(EBT, global.optimize.dotup, , EBTdoEliminateBottomTypes);
RUNOPT(DFC, TRUE, , DFCdoDispatchFunCalls);
RUNOPT(CF, global.optimize.docf, countCF = global.optcounters.cf_expr, CFdoConstantFolding);
RUNOPT(VP, global.optimize.dovp, countVP = global.optcounters.vp_expr, VPdoVarPropagation);
RUNOPT(ESD, global.optimize.dosde, , ESDdoElimSubDiv);
RUNOPT(AS, global.optimize.doas, countAS = global.optcounters.as_expr, ASdoArithmeticSimplification);
RUNOPT(CF, global.optimize.docf, countCF = global.optcounters.cf_expr, CFdoConstantFolding);
RUNOPT(CSE, global.optimize.docse, , CSEdoCommonSubexpressionElimination);
RUNOPT(AL, global.optimize.doal, countAL = global.optcounters.al_expr, ALdoAssocLawOptimization);
RUNOPT(DL, global.optimize.dodl, countDL = global.optcounters.dl_expr, DLdoDistributiveLawOptimization);
RUNOPT(UESD, global.optimize.dosde, , UESDdoUndoElimSubDiv);
RUNOPT(DCR, global.optimize.dodcr, , DCRdoDeadCodeRemoval);
However, this should just make compiles take longer (maxoptcyc, for
instance...).
2. Memory usage grows as saacyc runs, until we exhaust memory.
I tried running with -d treecheck, and got this:
Applying loop unrolling ...
LUR: -maxlur 3 would unroll loop
-> Running syntax tree checks
tree/check_lib.c:331 Assertion "NULL == AVIS_SSAASSIGN( ARG_AVIS( arg_node))" failed!
Non-NULL AVIS_SSAASSIGN in N_arg node
apex@rattler:~/apex3/benchmks/crc2AKD$ sac2c -doawlf -nowlf -v4 crc2AKD.sac -d treecheck -chkfreq 4 -noctzg -noedfa -nopetl
I do not know if this is the problem or not; I have my doubts, but will
let the keeper of LUR fix this particular bug.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1118Error messages from hell: foldfix stopper value causes confusion2017-11-19T20:23:13ZRobert BerneckyError messages from hell: foldfix stopper value causes confusion| | |
| --- | --- |
| Bugzilla Link | [967](http://bugs.sac-home.org/show_bug.cgi?id=967) |
| Created on | Jun 04, 2012 00:11 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/eaab446cc40e51d3...| | |
| --- | --- |
| Bugzilla Link | [967](http://bugs.sac-home.org/show_bug.cgi?id=967) |
| Created on | Jun 04, 2012 00:11 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/eaab446cc40e51d3947c001f1000af33/crud.sac) |
## Extended Description
<pre>Created an attachment (id=892)
source code to reproduce fault
** 11: Enhancing with-loops ...
**** Introducing explicit accumulators ...
flatten/ExplicitAccumulate.c:252 Assertion "eq_funap != NULL" failed!
sacprelude::eq not found
The problem is here:
inline bool andslXBBQUICKSTOP(bool[.] y)
{ /* First/last axis reduction of vector with quick stop*/
z = with {
(0*shape(y) <= iv < shape(y))
: BtoB(y[iv]);
} : foldfix( andBBB, true, 0);
return(z);
}
The "0" in the foldfix is wrong, but the error message
is not exactly informative.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1117EDFA crashes SSAT2017-11-19T20:23:10ZRobert BerneckyEDFA crashes SSAT| | |
| --- | --- |
| Bugzilla Link | [957](http://bugs.sac-home.org/show_bug.cgi?id=957) |
| Created on | May 20, 2012 17:23 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Build #17829 contains...| | |
| --- | --- |
| Bugzilla Link | [957](http://bugs.sac-home.org/show_bug.cgi?id=957) |
| Created on | May 20, 2012 17:23 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Build #17829 contains my latest -doedfa code, which attempts
to eliminate duplicate arguments from LACFUNs.
The generated code for the failing example looks OK to me,
but it does not look OK to SSAT, which crashes in RN_top in
SSATid: (SSATransform.c):
case RN_top:
new_avis = AVIS_SSASTACK_TOP( ID_AVIS( arg_node));
AVIS_SSASTACK_TOP has a pointer of some sort in it, but *AVIS_SSASTACK_TOP
is 57. Homage to Mr. Heinz?
Suggestions welcome.
This should break it:
sac2c -v1 -doedfa -nowlf -doawlf ~/sac/testsuite/optimizations/edfa/bug907BAKD.sac</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1116-d treecheck node set membership tests are wrong2017-11-19T20:23:07ZRobert Bernecky-d treecheck node set membership tests are wrong| | |
| --- | --- |
| Bugzilla Link | [956](http://bugs.sac-home.org/show_bug.cgi?id=956) |
| Created on | May 17, 2012 18:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This code is generate...| | |
| --- | --- |
| Bugzilla Link | [956](http://bugs.sac-home.org/show_bug.cgi?id=956) |
| Created on | May 17, 2012 18:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This code is generated in check.c:
/*
* Attribute check: AVIS_DECL
*/
if( ( FALSE)|| ( TRUE)){
CHKexistAttribute( AVIS_DECL( arg_node), arg_node, "mandatory attribute AVIS_DECL is NULL");
if( AVIS_DECL( arg_node)!= NULL){
if( !(( FALSE)|| ( NODE_TYPE( AVIS_DECL( arg_node))== N_vardec))){
CHKcorrectTypeInsertError(arg_node,"AVIS_DECL hasnt the right type."" It should be: ""N_vardec");
}
}
}
else if( ( FALSE)|| ( TRUE)){
CHKexistAttribute( AVIS_DECL( arg_node), arg_node, "mandatory attribute AVIS_DECL is NULL");
if( AVIS_DECL( arg_node)!= NULL){
if( !(( FALSE)|| ( NODE_TYPE( AVIS_DECL( arg_node))== N_arg))){
CHKcorrectTypeInsertError(arg_node,"AVIS_DECL hasnt the right type."" It should be: ""N_arg");
}
}
}
else {
CHKnotExist( AVIS_DECL( arg_node), arg_node, "attribute AVIS_DECL must be NULL");
The set membership test is incorrect, in that it will report
an error( expected N_vardec) if AVIS_DECL is an N_arg node,</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1115SISI is disabled by default, and crashes if enabled2017-11-19T20:23:03ZRobert BerneckySISI is disabled by default, and crashes if enabled| | |
| --- | --- |
| Bugzilla Link | [954](http://bugs.sac-home.org/show_bug.cgi?id=954) |
| Created on | May 15, 2012 14:22 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I just discovered tha...| | |
| --- | --- |
| Bugzilla Link | [954](http://bugs.sac-home.org/show_bug.cgi?id=954) |
| Created on | May 15, 2012 14:22 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I just discovered that SISI is NOT enabled by default, and
that it crashes (in SISI) if you enable it:
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17818:MODIFIED linux-gnu_x86_64
(Tue May 15 09:02:34 EDT 2012 by sac)
I was going to extend it to simplify LACFUN arguments
by removing duplicate shapes, but that pit has just grown a
bit deeper... Poop.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1114CSE repeats same job, perhaps caused by ESD2017-11-19T20:22:58ZRobert BerneckyCSE repeats same job, perhaps caused by ESD| | |
| --- | --- |
| Bugzilla Link | [953](http://bugs.sac-home.org/show_bug.cgi?id=953) |
| Created on | May 14, 2012 20:03 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>CSE, at least in the ...| | |
| --- | --- |
| Bugzilla Link | [953](http://bugs.sac-home.org/show_bug.cgi?id=953) |
| Created on | May 14, 2012 20:03 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>CSE, at least in the AWLFI micro-cycle, appears to be
repeating the same work over and over again.
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17817:MODIFIED linux-gnu_x86_64
(Mon May 14 13:38:24 EDT 2012 by sac)
SimplifySymb: SSE: DLIR= 0, WLIR= 0, INL=0, CSE=25, TUP=0, CF=0, VP=0, AS=0, AL=0, DL=0
SimplifySymb: SSE: Cycle interation 19...
This repeats until we reach maxoptcyc.
If I disable the call to ESD in the cycle, the problem does
not occur.
The fault can be seen with this call:
cd sac/apex/ipape
sac2c ipape.sac -doawlf -nowlf -v4 -#d,SSE</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1113integer overflows: -2 < maxint() is false in sac2017-11-19T20:22:55ZJaroslav Sýkorainteger overflows: -2 < maxint() is false in sac| | |
| --- | --- |
| Bugzilla Link | [951](http://bugs.sac-home.org/show_bug.cgi?id=951) |
| Created on | May 04, 2012 14:29 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [cmp.sac](/uploads/a7b9777eb4762350c...| | |
| --- | --- |
| Bugzilla Link | [951](http://bugs.sac-home.org/show_bug.cgi?id=951) |
| Created on | May 04, 2012 14:29 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [cmp.sac](/uploads/a7b9777eb4762350c42e437f425da2e9/cmp.sac) |
## Extended Description
<pre>Comparing (-2 < maxint()) returns false. See the attached source: it should print [true,true,true], but gives [true,false,false]. Tested on sac2c r17796.
_flat_3 = Constants::maxint() ; // 2147483647
_ctz_77 = _sub_SxS_( -2, _flat_3); // -2-2147483647 overflows to 2147483647
_pinl_48__flat_59 = _lt_SxS_( _ctz_77, 0); // compares 2147483647 < 0, giving false</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1112masterrun does not terminate due to ArrayFormatUT running forever2017-11-19T20:22:52ZSven-Bodo Scholzmasterrun does not terminate due to ArrayFormatUT running forever| | |
| --- | --- |
| Bugzilla Link | [949](http://bugs.sac-home.org/show_bug.cgi?id=949) |
| Created on | May 01, 2012 19:13 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>using sac2c rev.17794 a...| | |
| --- | --- |
| Bugzilla Link | [949](http://bugs.sac-home.org/show_bug.cgi?id=949) |
| Created on | May 01, 2012 19:13 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>using sac2c rev.17794 and
stdlib rev. 1624 and
sac rev 1664
the file testsuite/stdlib/modules/structures/ArrayFormatUT.sac compiles -mt fine but
the generated ArrayFormatUT_mt runs forever......</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1111buildv.sac AWLF blocked by failure to simplify guard on catenate2017-11-19T20:22:49ZRobert Berneckybuildv.sac AWLF blocked by failure to simplify guard on catenate| | |
| --- | --- |
| Bugzilla Link | [911](http://bugs.sac-home.org/show_bug.cgi?id=911) |
| Created on | Feb 15, 2012 21:52 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The APEX buildv.sac b...| | |
| --- | --- |
| Bugzilla Link | [911](http://bugs.sac-home.org/show_bug.cgi?id=911) |
| Created on | Feb 15, 2012 21:52 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The APEX buildv.sac benchmark constructs the vector:
(iota(0)),(iota(1)),(iota(2))...(iota(n))
by means of a fold WL. The result is generated
within the WL body by ++. The indexing operations
use this sort of guard when AWLF and/or -ecc/-check c are invoked:
_dup_2716__uprf_1576, _dup_2717__uprf_1577 =
_val_le_val_SxS_( _dup_2712__uprf_1581, _dup_2715__pinl_1144__flat_880);
currentshape[0] currentshape[0] + i
The right way to handle this is to perform comparison against zero,
as is done in min/max:
tmp = PRF_ARG - PRF_ARG1
val_le_val_SxS_( 0, tmp);
I hope this can be done by ICC, directly.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1110Buildv.sac appears to be missing reuse code2017-11-19T20:22:46ZRobert BerneckyBuildv.sac appears to be missing reuse code| | |
| --- | --- |
| Bugzilla Link | [910](http://bugs.sac-home.org/show_bug.cgi?id=910) |
| Created on | Feb 14, 2012 17:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [a.out.awlf](/uploads/9b1b800fd6a53c...| | |
| --- | --- |
| Bugzilla Link | [910](http://bugs.sac-home.org/show_bug.cgi?id=910) |
| Created on | Feb 14, 2012 17:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [a.out.awlf](/uploads/9b1b800fd6a53ca327c7cd0064367c47/a.out.awlf), [a.out.wlf](/uploads/5dd20850e28e470dc91a32e48c7270da/a.out.wlf), [crud.awlf](/uploads/aabbea776bb9fe76cfd594ac171dc2ce/crud.awlf), [crud.wlf](/uploads/2a8fdf9c28900897805ee82d549dc2e8/crud.wlf) |
## Extended Description
<pre>Created an attachment (id=848)
C code generated by sac2c -doawlf -nowlf -bopt
This code runs about twice as slow with -doawlf -nowlf as without:
use Array:all;
int main()
{
x = with {
([0] <= iv=[i] < [2000]) : iota(i);
} : fold( ++, [:int]);
z = sum(x);
StdIO::show(z);
return(0);
}
The IL codes at -bopt look, to my not-tutored-enough eyeballs, to be
almost identical. However, the generated C code shows that
the -doawlf version contains 15 for()-loops, whereas the -doawlf
version has only 13.
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17729:MODIFIED linux-gnu_x86_64
(Mon Feb 13 09:44:42 EST 2012 by sac)
This is not a new bug. Attached are the generated C codes and
the -bopt codes.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1109-profile dies in fun2lac.2017-11-19T20:22:40ZRobert Bernecky-profile dies in fun2lac.| | |
| --- | --- |
| Bugzilla Link | [908](http://bugs.sac-home.org/show_bug.cgi?id=908) |
| Created on | Feb 10, 2012 17:00 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>No idea how long this...| | |
| --- | --- |
| Bugzilla Link | [908](http://bugs.sac-home.org/show_bug.cgi?id=908) |
| Created on | Feb 10, 2012 17:00 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>No idea how long this has been broken. The problem lies in fun2lac,
but I have no idea how to fix it.
cat crud2.sac
use Array:{<,++,+};
int main()
{
x = [2,3,5];
z = 0;
for( i=0; i<3; i++) {
z = z + _sel_VxA_([i], x);
}
StdIO::print(z);
return(0);
}
sac2c crud2.sac -v1 -profile l
flatten/fun2lac.c:293 Assertion "FALSE" failed!
Control flow should not reach here
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17728 linux-gnu_x86_64
(Fri Feb 10 11:48:32 EST 2012 by sac)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1108Livermore Loop09 poor performance with sparse-vector/matrix multiply2017-11-19T20:22:37ZRobert BerneckyLivermore Loop09 poor performance with sparse-vector/matrix multiply| | |
| --- | --- |
| Bugzilla Link | [907](http://bugs.sac-home.org/show_bug.cgi?id=907) |
| Created on | Jan 22, 2012 21:50 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [loop09.sac](/uploads/ec6b1360cee8e6...| | |
| --- | --- |
| Bugzilla Link | [907](http://bugs.sac-home.org/show_bug.cgi?id=907) |
| Created on | Jan 22, 2012 21:50 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [loop09.sac](/uploads/ec6b1360cee8e6b0a7bb29708f7bd64b/loop09.sac), [crud.simple.sac](/uploads/272cf9eec0975000542d117cac2242e6/crud.simple.sac), [condfun.sac](/uploads/8c98f518133505d73778103cd24f7633/condfun.sac) |
## Extended Description
<pre>Created an attachment (id=845)
source code to reproduce failure
I rewrote loop09 to use a sparse-vector vs. dense matrix inner product
function, which made the code much more readable and maintainable.
Unfortunately, it's also much slower than the scalar-oriented C code.
It should not be, so I had a look into it. There are several
LACFUN-related problems, and AWLF suffers from all of them:
1. The loop09 code uses a FOR-loop of the form: (i=0; i<lim; i++).
We currently have no way to provide i with extrema. This causes
a number of problems with AWLF, guards, CF, etc.
I was going to pass extrema into/out of LACFUNs, but that would
not help here, because there are no steenking extrema.
Some ways we might deal with this problem:
a. Provide a "serial-WL" that offers a stricter format for
induction variable specification.
b. Provide kludge code to analyze FOR-loop induction variables,
when the patterns are simple (as above).
c. Since the FOR-loop can actually be performed in parallel,
we could design a "conditional-WL" that allows some
iterations to provide no result cell. In the case of a fold-WL,
this means that those cells do not enter into the
reduction step. For a genarray, those cells are not in the result.
These all would not have any benefit until I get AVIS_MIN/MAX
passed in and out of LACFUNs.
2. Shape analysis within LACFUNs suffers, because AVIS_SHAPE
information is passed into a LACFUN as an N_id. This means that
useful information, such as (shape(vec)[0]) == (shape(mat)[0])
is lost. This cripples AWLF and some guard CF.
I don't know a good way to fix this. Perhaps AVIS_SHAPE should
be allowed to be an N_array of N_id nodes? I think that would work.
3. All of the above contribute to another problem: AWLF ends up slicing
cubes when it is not needed. Worse yet, it then fails to do
the folding on the sliced cube. Fixing this might be messy
for higher-dimensional cubes, but I'm not sure.
Suggestions and comments are very welcome.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1107Livermore Loop09 ast corrupted by EBT at end of -bopt2017-11-19T20:22:32ZRobert BerneckyLivermore Loop09 ast corrupted by EBT at end of -bopt| | |
| --- | --- |
| Bugzilla Link | [904](http://bugs.sac-home.org/show_bug.cgi?id=904) |
| Created on | Jan 17, 2012 16:53 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/7c6ba4ff06b4bc7c...| | |
| --- | --- |
| Bugzilla Link | [904](http://bugs.sac-home.org/show_bug.cgi?id=904) |
| Created on | Jan 17, 2012 16:53 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/7c6ba4ff06b4bc7cc2fbcfa933e8a452/crud.sac) |
## Extended Description
<pre>Created an attachment (id=842)
source code to reproduce failure
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17723 linux-gnu_x86_64
(Fri Jan 13 16:39:25 EST 2012 by sac)
sac@rattler:~/sac/demos/benchmarks/livermore_loops/for_comparison/loop09$ sac2c crud.sac -bopt:ebt -d treecheck -chkfreq 4 -v1 -nosaacyc -noive >crud
The failure mode is this:
If left to itself, things crash in: IVESLIdoIVESplitLoopInvariants,
with:
tree/infer_dfms.c:312 Assertion "N_avis == NODE_TYPE(avis)" failed!
avis expected
However, -bopt:ebt shows that the damage has occurred much earlier.
The bug appeared with the rewrite of vecmatmul, as follows:
inline double[N] vecmatmul( double[25] wts, double[N,25] PX)
{
colsx = shape(wts)[0];
colsy = shape(PX)[dim(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);
}</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1106Livermore Loop08 confuses CSE2017-11-19T20:22:29ZRobert BerneckyLivermore Loop08 confuses CSE| | |
| --- | --- |
| Bugzilla Link | [903](http://bugs.sac-home.org/show_bug.cgi?id=903) |
| Created on | Jan 16, 2012 20:10 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [loop08.sac](/uploads/ea9868a3998298...| | |
| --- | --- |
| Bugzilla Link | [903](http://bugs.sac-home.org/show_bug.cgi?id=903) |
| Created on | Jan 16, 2012 20:10 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [loop08.sac](/uploads/ea9868a399829802c725944bb2aa7c95/loop08.sac) |
## Extended Description
<pre>Created an attachment (id=841)
source code to reproduce failure
AWLFIfundef: AWLFI: Algebraic-With-Loop-Folding Inference in function _dup_23807_shift__Loop_58 ends
SimplifySymb: SSE: Entering opt micro-cycle for function Loop8
SimplifySymb: SSE: LIR= 0, INL=0, CSE=10873, TUP=0, CF=37, VP=670, AS=0, AL=2, DL=0
SimplifySymb: SSE: LIR= 0, INL=0, CSE=195, TUP=0, CF=0, VP=14, AS=0, AL=0, DL=0
SimplifySymb: SSE: LIR= 0, INL=0, CSE=190, TUP=0, CF=0, VP=0, AS=0, AL=0, DL=0
SimplifySymb: SSE: LIR= 0, INL=0, CSE=190, TUP=0, CF=0, VP=0, AS=0, AL=0, DL=0
SimplifySymb: SSE: LIR= 0, INL=0, CSE=190, TUP=0, CF=0, VP=0, AS=0, AL=0, DL=0
SimplifySymb: SSE: LIR= 0, INL=0, CSE=190, TUP=0, CF=0, VP=0, AS=0, AL=0, DL=0
SimplifySymb: SSE: LIR= 0, INL=0, CSE=190, TUP=0, CF=0, VP=0, AS=0, AL=0, DL=0
SimplifySymb: SSE: LIR= 0, INL=0, CSE=190, TUP=0, CF=0, VP=0, AS=0, AL=0, DL=0
SimplifySymb: SSE: LIR= 0, INL=0, CSE=190, TUP=0, CF=0, VP=0, AS=0, AL=0, DL=0
SimplifySymb: SSE: LIR= 0, INL=0, CSE=190, TUP=0, CF=0, VP=0, AS=0, AL=0, DL=0
SimplifySymb: SSE: Stabilized at iteration 9 for function Loop8
AWLFIfundef: AWLFI: Algebraic-With-Loop-Folding Inference in function Loop8 ends
This fails here, but I suspect it is not a new problem:
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17723 linux-gnu_x86_64
(Fri Jan 13 16:39:25 EST 2012 by sac)
~/sac/demos/benchmarks/livermore_loops/for_comparison/loop08$ sac2c loop08.sac -doawlf -nowlf -bopt -v4 -#d,AWLFI,SSE &>crud
The SSE code in AWLFI calls the listed traversals in its own microcycle,
including a DCR call not shown above. Oddly enough, CSE keeps finding
the same expressions, even though they should be gone after the first
pass. This causes the microcycle to run until maxoptcyc. Not a good thing.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1105LACFUN loses AKV-ness of array shape2017-11-19T20:22:25ZRobert BerneckyLACFUN loses AKV-ness of array shape| | |
| --- | --- |
| Bugzilla Link | [902](http://bugs.sac-home.org/show_bug.cgi?id=902) |
| Created on | Jan 13, 2012 18:26 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [xcrud.sac](/uploads/ed87ea353523c99...| | |
| --- | --- |
| Bugzilla Link | [902](http://bugs.sac-home.org/show_bug.cgi?id=902) |
| Created on | Jan 13, 2012 18:26 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [xcrud.sac](/uploads/ed87ea353523c994fa7baa66551ddb01/xcrud.sac), [crud.sac](/uploads/5899d246517e177bfc0a61de43272ced/crud.sac) |
## Extended Description
Created an attachment (id=839)
source code to reproduce failure
I have been looking at Livermore Loop loop01.sac, of which I am attaching a
simpler version for analysis.
WLF and AWLF are both failing in Loop1, because Loop1 (which is not a loop,
by the way...) has a parameter "int n", which is AKV in its calling
environment, but AKS in Loop1.
I don't know who is to blame, but the results are unfortunate.
I will look into this further after lunch. Piss.BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1104Problems trying to use icc with -dophm2017-11-19T20:22:21ZRobert BerneckyProblems trying to use icc with -dophm| | |
| --- | --- |
| Bugzilla Link | [901](http://bugs.sac-home.org/show_bug.cgi?id=901) |
| Created on | Jan 13, 2012 17:36 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This is likely a simp...| | |
| --- | --- |
| Bugzilla Link | [901](http://bugs.sac-home.org/show_bug.cgi?id=901) |
| Created on | Jan 13, 2012 17:36 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This is likely a simple problem in configuration,
but I am unable to use the Intel icc compiler with sac2c.
Here's what I have:
sac2c foo.sac -target intelcc_rbe
Several problems, actually:
P1;
sac2c -h
describes -target as looking at $SACBASE/runtime/sac2crc.
This does not exist. What does exist are:
$SAC2CBASE/sac2crc
and
$SAC2CBASE/setup/sac2crc
It is not obvious which of these I should edit, nor does
the compiler tell you which one it was looking at if you
do something like: sac2c -target NoSuchTarget
P2: I get this if I compile with what looks like a simple
variant of -target intelcc:
ipo: remark #11001: performing single-file optimizations
ipo: remark #11006: generating object file /tmp/ipo_icc3yenGL.o
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu/libc.a(malloc.o): In function `free':
(.text+0x5180): multiple definition of `free'
/home/sac/sac2c/lib//libsacphm.seq.a(malloc.p.seq.o):/home/sac/sac2c/src/libsacphm/compat/malloc.c:212: first defined here
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu/libc.a(malloc.o): In function `malloc':
(.text+0x4bb0): multiple definition of `malloc'
/home/sac/sac2c/lib//libsacphm.seq.a(malloc.p.seq.o):/home/sac/sac2c/src/libsacphm/compat/malloc.c:80: first defined here
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu/libc.a(malloc.o): In function `realloc':
(.text+0x5250): multiple definition of `realloc'
/home/sac/sac2c/lib//libsacphm.seq.a(malloc.p.seq.o):/home/sac/sac2c/src/libsacphm/compat/malloc.c:288: first defined here
ABORT: System failed to execute shell command
ABORT: icc -shared-intel -xsse4.2 -fast -msse3 -simd -ipo -opt-prefetch
ABORT: -ldl -lpthread -I$SAC2CBASE/include/ -L$SAC2CBASE/lib/
ABORT: -L/tmp/SAC_NJvA1x -o intel.out intel.out.c -L. -Wl,-rpath,.
ABORT: -L/home/sac/sac2c/lib -Wl,-rpath,/home/sac/sac2c/lib
ABORT: -L/home/sac/sac/BASE/stdlib/modules/structures/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/modules/structures/lib
ABORT: -L/home/sac/sac/BASE/stdlib/modules/numerical/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/modules/numerical/lib
ABORT: -L/home/sac/sac/BASE/stdlib/modules/numerical/blas/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/modules/numerical/blas/lib
ABORT: -L/home/sac/sac/BASE/stdlib/modules/unibench/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/modules/unibench/lib
ABORT: -L/home/sac/sac/BASE/stdlib/modules/auxiliary/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/modules/auxiliary/lib
ABORT: -L/home/sac/sac/BASE/stdlib/modules/mutc/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/modules/mutc/lib
ABORT: -L/home/sac/sac/BASE/stdlib/world/mutc/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/world/mutc/lib
ABORT: -L/home/sac/sac/BASE/stdlib/world/system/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/world/system/lib
ABORT: -L/home/sac/sac/BASE/stdlib/world/stdio/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/world/stdio/lib
ABORT: -L/home/sac/sac/BASE/stdlib/world/stdio/dislin/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/world/stdio/dislin/lib
ABORT: -L/home/sac/sac/BASE/stdlib/world/stdio/gnuplot/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/world/stdio/gnuplot/lib
ABORT: -L/home/sac/sac/BASE/stdlib/classes/random/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/classes/random/lib
ABORT: -L/home/sac/sac/BASE/stdlib/classes/auxiliary/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/classes/auxiliary/lib
ABORT: -L/home/sac/sac/BASE/stdlib/utrace/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/utrace/lib -L. -Wl,-rpath,.
ABORT: -L/usr/local/dislin -Wl,-rpath,/usr/local/dislin -L/opt/local/lib
ABORT: -Wl,-rpath,/opt/local/lib -lStdIOMod -lBinFileMod -lFibreIOMod
ABORT: -lListIOMod -lComplexIOMod -lColor8IOMod -lGreyIOMod -lArrayIOMod
ABORT: -lScalarIOMod -lStringArrayMod -lRuntimeErrorMod -lIOresourcesMod
ABORT: -lArrayFormatMod -lStructuresMod -lBitsMod -lComplexMod -lListMod
ABORT: -lColor8Mod -lGreyMod -lFileMod -lTermFileMod -lTerminalMod
ABORT: -lFileSystemMod -lArrayMod -lMathArrayMod -lComplexArrayTransformMod
ABORT: -lComplexArrayArithMod -lArrayTransformMod -lSysErrMod -lWorldMod
ABORT: -lStringMod -lConstantsMod -lArrayArithMod -lComplexScalarArithMod
ABORT: -lComplexArrayBasicsMod -lComplexBasicsMod -lBoolMod -lCharMod
ABORT: -lArrayBasicsMod -lMathMod -lm -lScalarArithMod -lsacpreludeMod
ABORT: -lsacphm.seq -lsac.seq -pthread -ldl
ABORT: with exit code 1
If I compile with -nophm, this goes away, but performance is dismal.
The presence of "gcc" in the above suggests that I am not getting the
correct libc, but it's not clear from looking at sac2crc (either of
them) how I should fix this.
My entry for intelcc_rbe looks like this:
target intelcc_rbe::intelcc:
>
> CCFLAGS += " -fast -msse3 -simd -ipo -opt-prefetch"
It seems odd that intelcc (directly above this entry) works,
but that my entry does not.
Suggestions welcome.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1103with-loop with empty iteration space found when compiling with -noopt2017-11-19T20:22:18ZRobert Berneckywith-loop with empty iteration space found when compiling with -noopt| | |
| --- | --- |
| Bugzilla Link | [896](http://bugs.sac-home.org/show_bug.cgi?id=896) |
| Created on | Dec 23, 2011 20:23 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud2.sac](/uploads/aa6b6bb063c03ad...| | |
| --- | --- |
| Bugzilla Link | [896](http://bugs.sac-home.org/show_bug.cgi?id=896) |
| Created on | Dec 23, 2011 20:23 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud2.sac](/uploads/aa6b6bb063c03add982feccba052f54d/crud2.sac) |
## Extended Description
<pre>Created an attachment (id=835)
source code to reproduce failure
The attached fails when compiled with:
sac2c crud2.sac -noopt
wltransform/wltransform.c:7107 Assertion "FALSE" failed!
with-loop with empty iteration space found!
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17714:MODIFIED linux-gnu_x86_64
(Tue Dec 20 16:34:06 EST 2011 by sac)</pre>BugZillaBugZilla