RFR(S): 8202949: C2: assert(false) failed: Bad graph detected in build_loop_late
rwestrel at redhat.com
Wed May 23 11:58:54 UTC 2018
> We crash during loop opts verification because memory from a non-dominating path is consumed by a
> MemBarReleaseNode. The problem is that a range check dependent CastII is removed because the type of
> the input value is always in bounds. The corresponding ConvI2L floats up during loop optimizations
> and becomes TOP because the loop induction variable of the unrolled loop is out of bounds. As a
> result, the memory graph is corrupted with memory consuming nodes still being reachable because the
> dead loop is not (yet) removed (Opaque1 nodes are still guarding the bounds). See comment in test
> for details.
> Range check dependent CastIIs were introduced to fix JDK-6675699 and should not be removed. The
> offending code was introduced by JDK-8139771.
Isn't it the case that the CastII and the ConvI2L have the same type i.e
0..9? So if you leave the CastII in, why doesn't it become top?
More information about the hotspot-compiler-dev