Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • sac2c sac2c
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 400
    • Issues 400
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 12
    • Merge requests 12
  • Deployments
    • Deployments
    • Releases
  • Wiki
    • Wiki
  • External wiki
    • External wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • sac-group
  • sac2csac2c
  • Issues
  • #1119
Closed
Open
Created Jun 07, 2012 by Robert Bernecky@rbeDeveloper

apex benchmark crc2AKD.sac runs out of memory

Bugzilla Link 974
Created on Jun 07, 2012 19:29
Version svn
OS Linux
Architecture PC
Attachments crc2AKD.sac

Extended Description

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.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking