RFR: 8320308: C2 compilation crashes in LibraryCallKit::inline_unsafe_access

[Tobias Holenstein]

On Fri, 6 Sep 2024 19:45:43 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> > I think Vladimir's question is: how can null_check_oop() return top? AFAIU, it creates a CastPP with 147 as input and that CastPP is transformed to top. How does that happen? What are the steps in the call to _gvn.transform( cast ); that lead to a result of top.
> 
> I think that what should happen when compiler tries to cast a value to an empty type in a dead code.
> 
> Toby's response answered my question: it's a GVN on `CmpP` which determines that both inputs are `NULL` and degenerates the check into an unconditional uncommon trap. (I believe it's `in1->eqv_uncast(in2)` in `SubNode::Value_common()` which does the job.) In such case, performing `base->uncast()` in `LibraryCallKit::classify_unsafe_addr()` seems appropriate to me.

Yes, this is exactly what's happening - `in1->eqv_uncast(in2) in `SubNode::Value_common()` determines that both inputs are NULL, which degenerates the check into an unconditional uncommon trap. I've updated the PR to use `base->uncast()` in `LibraryCallKit::classify_unsafe_addr()` as the new fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/20033#issuecomment-2357914987