RFR(XS): 8229450: C2 compilation fails with assert(found_sfpt) failed

[Liu Xin]

Tobias,

You are right.  Actually, prevdom will be killed right after dominated_by,
so it's more clear to assign out_le to prevdom.
Here is the new CR.  verified by hotspot:tier1.
https://cr.openjdk.java.net/~xliu/8229450/05/webrev/

On Tue, Sep 3, 2019 at 2:25 AM Tobias Hartmann <tobias.hartmann at oracle.com>
wrote:

> 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
>
>