RFR: 8332827: [REDO] C2: crash in compiled code because of dependency on removed range check CastIIs

Roland Westrelin roland at openjdk.org
Wed Dec 11 15:06:48 UTC 2024


On Wed, 11 Dec 2024 07:41:33 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> The failures that caused the backout were due to a bug in:
>> 
>> `find_or_make_integer_cast()`
>> 
>> which caused the `_range_check_dependency` field's value of the
>> existing cast node to not be set in the new cast node. I re-ran some
>> testing with this fixed and current jdk repo and found that a few
>> vectorization tests fail now because the patch pushes range check
>> `CastII` nodes through `AddI`/`SubI`. To fix this, I delayed that
>> transformation to after loop opts.
>
> src/hotspot/share/opto/compile.cpp line 3147:
> 
>> 3145:     DivModNode* divmod = DivModNode::make(n, bt, is_unsigned);
>> 3146:     divmod->add_prec_from(n);
>> 3147:     divmod->add_prec_from(d);
> 
> Can you explain why you added this?

If the divisor input for a `Div` (or `Mod` etc.) is not not null, then the control input of the `Div` is set to null. It could be that the divisor input is found not null because the subgraph for that input contains a `CastII`. If that happens, removing the `CastII` during final graph reshap could cause the `Div` to float above the `CastII` and above the condition that allowed the type of the `CastII` to be narrowed. This could cause a crash. 
So when the `CastII` is removed, precedence edges are aded to the `Div` node. If the `Div` is then replaced by a `DivMod`, we need to transfer the precedence edges to the `DivMod` node.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22568#discussion_r1880370799


More information about the hotspot-compiler-dev mailing list