RFR(S): 8202949: C2: assert(false) failed: Bad graph detected in build_loop_late
rwestrel at redhat.com
Wed May 23 13:09:27 UTC 2018
> Because the CastII is range check (control) dependent and can therefore not flow up/around during
> loop optimizations. In the end (when OpaqueNodes go away), all that dead code is removed anyway but
> in the failing case the problem really is that the memory path becomes dead due to the ConvI2L
> moving up while the control path is still there (and not yet known to be dead as well). The sole
> purpose of the range check dependent CastIIs was to avoid this inconsistency (see JDK-6675699).
Where does the ConvI2L move up to?
It's dependent on the induction variable so it can't go very far?
Are we talking about the main loop after unrolling?
More information about the hotspot-compiler-dev