RFR(XS): 8229450: C2 compilation fails with assert(found_sfpt) failed
Tobias Hartmann
tobias.hartmann at oracle.com
Tue Sep 3 09:25:27 UTC 2019
Hi,
On 03.09.19 08:20, Liu Xin wrote:
> https://cr.openjdk.java.net/~xliu/8229450/04/webrev/
I think this still needs some refactoring:
- In line 1352, you are casting a pointer to boolean. You can simply move the check to line 1347 and
initialize out_le depending on 'is_inner_of_stripmined_loop'. Or why not just update prevdom there?
- The comments in 1195 - 1198 should be moved to line 1347 because they are unrelated to the method.
- Use "Node* var" instead of "Node *var" for new code (yes, existing code uses different formats).
> I have yet another proposal. Can I file a JBS issue to avoid a short trip-counted loop from
> trip-mining?
>
> My original program has a very short trip-counted loop. The upper-bound 4 is significantly smaller
> than LoopStripMiningIter.
> Loop: N355/N216 limit_check counted [0,4),+1 (-1 iters) has_sfpt strip_mined
>
> This predicate doesn't consider trip-counted loop and its constant limit.
> bool strip_mine_loop = LoopStripMiningIter > 1 && loop->_child == NULL &&
> sfpt2->Opcode() == Op_SafePoint && !loop->_has_call
>
> I think the original motivation for strip-mining is for GC? if a loop is super hot, GCs don't have
> a chance to chime in.
> A short trip-counted loop should not a problem for GC. if it has function call, call node will have
> a safepoint itself.
I leave this for Roland to answer, he's the loop strip mining expert :)
Best regards,
Tobias
More information about the hotspot-compiler-dev
mailing list