RFR: 8290432: C2 compilation fails with assert(node->_last_del == _last) failed: must have deleted the edge just produced [v3]

Yi Yang yyang at openjdk.org
Wed Nov 16 02:31:00 UTC 2022


On Thu, 8 Sep 2022 07:19:10 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> > Why? Can you clarify more?
> 
> As I mentioned above, I don't understand how your newly added condition is supposed to work.

@vnkozlov @TobiHartmann  I reviewed the above comments again. I think the proposed fix is good. According to my analysis at https://github.com/openjdk/jdk/pull/9695#issuecomment-1206221152 , we have a parallel IV which formed as `Add->CastII->Phi`, the birth of the form looks good, and this pattern is only legal after [JDK-8273585](https://bugs.openjdk.org/browse/JDK-8273585). In that case, `Add->CastII->Phi` parallel IV was generated by Preconditions.checkIndex, CastII was controlled by  ConstraintCast. In the proposed fix, I'm trying to avoid to recognize similar pattern if CastII was not controlled by ConstraintCast.



I reviewed the previous discussion and I think this fix is ok. According to my analysis(https://github.com/openjdk/jdk/pull/9695#issuecomment-1206221152 ), the entire IR(Add-CastII-Phi) generation is reasonable, and this format is only valid after [JDK-8273585](https://bugs.openjdk.org/browse/JDK-8273585). In that case, CastII is controlled by ConstraintCast, so in the current patch, we refuse to recognize other cases besides this. As far as this fix itself is concerned, I think the whole process is reasonable. The only thing I'm not sure about is whether this Add-CastII-Phi form is really reasonable as an IV, which is why I think adding an IR verification test for [JDK-8273585](https://bugs.openjdk.org/browse/JDK-8273585) is reasonable, I will go back to investigate that again after this patch, what do you think?

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

PR: https://git.openjdk.org/jdk/pull/9695


More information about the hotspot-compiler-dev mailing list