> So for the loop that starting at bb 28 you can see the xxtrt_46 access was not
> put into pretemp. Possible reason is exactly as it was mentioned by Richard -
> there were extra candidates collected and this one become less anticipatable
>
> Skipping partial partial redundancy for expression
> {array_ref<pretmp_8,0,4>,mem_ref<0B>,xxtrt_46(D)}@.MEM_30(D) (0165)
> not partially anticipated on any to be optimized for speed edges
> -----------------------------------------------------------------------
> Found partial partial redundancy for expression
> {array_ref<pretmp_8,0,4>,mem_ref<0B>,xxtrt_46(D)}@.MEM_30(D) (0165)
> Created phi prephitmp_237 = PHI <_88(90), _85(29)>
> in block 30
Hmm, interesting, what is the edge resonsible?
I would expect it to be the loopback edge and its frequency is:
;; basic block 28, loop depth 0, count 0, freq 1998, maybe hot
;; prev block 92, next block 94, flags: (NEW, REACHABLE)
;; pred: 92 [100.0%, 180] (FALLTHRU)
;; 96 [100.0%, 1818] (FALLTHRU,DFS_BACK)
# ival2_136 = PHI <ival2_62(92), ival2_144(96)>
# ival2_140 = PHI <ival2_80(92), ival2_146(96)>
_137 = (integer(kind=8)) ival2_136;
_138 = _137 + -1;
_139 = *xxtrt_25(D)[_138];
_141 = (integer(kind=8)) ival2_140;
_142 = _141 + -1;
_143 = *xxtrt_25(D)[_142];
if (_139 < _143)
goto <bb 29>;
else
goto <bb 94>;
1818 that should be still hot. Or isn't the heuristic backwards? I.e. I would
expect
the partial anticipance to sit on edge 92->28 (with freq 180) where we need to
insert
the computation to get the other path hot.
Honza
