RFR: 8349139: C2: Div looses dependency on condition that guarantees divisor not null in counted loop

[Roland Westrelin]

On Thu, 13 Feb 2025 17:19:45 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> > For any `Phi`? This seems like an issue that's specific to the counted loop iv. I don't think we want to add `CastII` nodes unless we're sure they are needed.
> 
> I think it is probably because we are more aggressive with the type of loop phis. Conceptually, a `Phi` is pinned, and idealizing it into a floating node is incorrect. So, there may be issues lurking around due to this. We can introduce another phase that tries to remove all `CastNode` and pins all nodes that need that dependency (such as `Div`, loads, etc). What do you think?

In general a `Phi`'s type is the union of the types of its inputs. There's no narrowing happening at the `Phi`. So I don't think there's any implicit dependency from some floating node that uses the `Phi` on the `Phi`'s `Region`.

Counted loops are a bit different: the loop's `Phi` is the union of the type of the value on loop entry and a narrowed type for the value flowing through the backedge. The loop exit condition is what narrows the type the value that flows along the backedge and, as a result, of the loop `Phi`.  

Trouble occurs when the loop is cloned by pre/main/post. Then the `Phi` for the main or post loop inherits the type of the `Phi` before transformation, the one that depends on the loop exit condition. Say the pre loop runs iterations 0 to p and the main loop runs iteration p+1 to m. In the loop before transformation, to reach iteration p+1, we have to go through the backedge at least once. One pre/main/post loops are created, going through the backedge to reach iteration p+1 implies exiting the pre loop and passing the zero trip guard for the main loop. So the type of the main loop's `Phi` is dependent on the zero trip guard for the main loop which is why we need the `CastII`.

AFAICT, this issue really only exists for counted loop `Phi`s and once some transformation has "unfolded" the loop exit test. Now that I think more about it, a similar issue may happen with peeling (I will look into that separately). But I don't think it's a generic issue that affects all `Phi`s and as such it should be fixed by adding extra dependencies where they are needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/23617#issuecomment-2659784027