sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T20:32:02Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1223LIR misses out on arrays2017-11-19T20:32:02ZRobert BerneckyLIR misses out on arrays| | |
| --- | --- |
| Bugzilla Link | [1189](http://bugs.sac-home.org/show_bug.cgi?id=1189) |
| Created on | Mar 07, 2017 20:20 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug2.sac](/uploads/5033dc42bf1350...| | |
| --- | --- |
| Bugzilla Link | [1189](http://bugs.sac-home.org/show_bug.cgi?id=1189) |
| Created on | Mar 07, 2017 20:20 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug2.sac](/uploads/5033dc42bf1350a21e2cc4f5fe0e6ff8/bug2.sac) |
## Extended Description
<pre>Created an attachment (id=1059)
source code to reproduce failure
In my local Build: sac2c -V
sac2c 1.2-beta-BlackForest-400-g48da-dirty
build-type: DEBUG
built-by: "sac" at 2017-03-06T17:21:34
I observed the following, compiling with default options:
bool[20] _MAIN::_dup_863_main__Loop_0( bool[20] _dup_3532_Zrow { ,NN } , int colx { ,NN } )
/*
* _dup_863_main__Loop_0 :: ---
*/
{
int _al_868 { , NN } ;
int _pinl_547__flat_32 { , NN } ;
bool _pinl_548__flat_67 { , NN } ;
bool[20] Crow__SSA0_3 { , NN } ;
bool[20] Crow__SSA0_2 { , NN } ;
_pinl_547__flat_32 = _add_SxS_( 1, colx);
_al_868 = _add_SxS_( -19, colx);
_pinl_548__flat_67 = _lt_SxS_( _al_868, 0);
if (_pinl_548__flat_67)
{
Crow__SSA0_2 = _MAIN::_dup_863_main__Loop_0( _dup_3532_Zrow, _pinl_547__flat_32) ;
}
else
{
}
Crow__SSA0_3 = ( _pinl_548__flat_67 ? Crow__SSA0_2 : _dup_3532_Zrow );
return( Crow__SSA0_3);
}
Note that _dup_3532_Zrow is loop-invariant, yet it does not get lifted
out of the loop.
I am looking into this now.</pre>Jing GuoJing Guohttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1222LIR fails to lift loop-invariant N_arg used only in GENARRAY_DEFAULT2017-11-19T20:31:59ZRobert BerneckyLIR fails to lift loop-invariant N_arg used only in GENARRAY_DEFAULT| | |
| --- | --- |
| Bugzilla Link | [1151](http://bugs.sac-home.org/show_bug.cgi?id=1151) |
| Created on | Apr 01, 2015 20:57 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [buglur.sac](/uploads/2123cdafa821...| | |
| --- | --- |
| Bugzilla Link | [1151](http://bugs.sac-home.org/show_bug.cgi?id=1151) |
| Created on | Apr 01, 2015 20:57 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [buglur.sac](/uploads/2123cdafa821cd85dc8d4f6c391ff935/buglur.sac) |
## Extended Description
<pre>Created an attachment (id=1034)
source code to cause failure
This failure causes a performance loss in the attached, because LIR fails to detect that a constant LOOPFUN argument is referenced only by
a WL GENARRAY_DEFAULT.
DLIR_WITH was traversing WITH_WITHOP, but it did not look at any
of its sons. I introduced DLIRgenarray, with a TRAVsons, which does
get us to DLIRid, where the offending variable is marked as
AVIS_SSALPIV, but it still does not get removed, so I am missing
something else. I'll check in this change in a day or so, unless
somebody is keen to look at the fault.</pre>Jing GuoJing Guohttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1221LIR misses WL in CONDFUN2017-11-19T20:31:55ZRobert BerneckyLIR misses WL in CONDFUN| | |
| --- | --- |
| Bugzilla Link | [1019](http://bugs.sac-home.org/show_bug.cgi?id=1019) |
| Created on | Aug 31, 2012 23:04 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbb.sac](/uploads/f1d4cc814ec280...| | |
| --- | --- |
| Bugzilla Link | [1019](http://bugs.sac-home.org/show_bug.cgi?id=1019) |
| Created on | Aug 31, 2012 23:04 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbb.sac](/uploads/f1d4cc814ec28049cfa0cdb68796237f/ipbb.sac) |
## Extended Description
<pre>Created an attachment (id=929)
source code to reproduce fault
Recently, I loosened up the rules for WLPROP, in
the hope of making a number of benchmarks run
better, as well as making WLPROP work on CONDFUNs.
However, I see today that some benchmarks, e.g., apex/ipbb/ipbb.sac,
run a LOT slower, and the cause is a WL that is being
WLPROP'd into a CONDFUN, but is not being LIR'd back
out when AWLF/WLF fail to gobble up that WL.
I tried tightening up the WLPROP rules to their previous
state, with no luck. Running with -nowlprop avoids
the problem, but that takes all the fun out of things.
It may be that LIR never dealt with CONDFUNs. If so, that
would certainly explain the problem.
The failure definitely happens with Build #18200.
I'll look into the problem over the weekend. After all,
it IS Labor Day here, so I may as well be laboring.</pre>Jing GuoJing Guohttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1217LIR ineffective in opt cycles2017-11-19T20:31:42ZClemens GrelckLIR ineffective in opt cycles| | |
| --- | --- |
| Bugzilla Link | [860](http://bugs.sac-home.org/show_bug.cgi?id=860) |
| Created on | Aug 21, 2011 09:44 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [lir.sac](/uploads/5c979f5350a7614ca...| | |
| --- | --- |
| Bugzilla Link | [860](http://bugs.sac-home.org/show_bug.cgi?id=860) |
| Created on | Aug 21, 2011 09:44 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [lir.sac](/uploads/5c979f5350a7614ca7e32b76f2166192/lir.sac) |
## Extended Description
<pre>When compiling the unit test testsuite/optimizations/al/lir.sac
AL identifies the loop invariant variables in the first opt cycle
and rearranges the multi-operand expression accordingly.
However, none of the LIRs in the two opt cycles actually removed the
loop invariant expression and, hence, it is identified again and again
by AL. Only the final off-cycle application of LIR does its job. In a
less trivial example that, of course, would be too late for other
optimisations to benefit.
Funny enough, despite the fact that lir and wlir go together (as they
should not) the similar wlir.sac unit test works fine.</pre>Jing GuoJing Guo