RFR: 8350864: C2: verify structural invariants of the Ideal graph [v3]

[Marc Chevalier]

On Fri, 5 Sep 2025 07:41:24 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>>>  We would have to find a solution if there would be multiple bindings though ... I think that's not possible with your patterns, right? Is that a fundamental constraint?
>> 
>> Not sure what you mean? `And::make(new Bind(bla), AtInput(1, new Bind(bli)))`? You probably mean something else.
>> 
>> 
>>> If we could somehow already cast the Bind variable to Region. Could be tricky.
>>> Doing this is_Region and bind could be a very common idiom, so very useful.
>> 
>> Interesting... Not sure how with some template magic we don't have (like `Node::is<RegionNode>`) but probably doable with macros. I'll give it a try.
>
>> We would have to find a solution if there would be multiple bindings though ... I think that's not possible with your patterns, right? Is that a fundamental constraint?
> 
> Sorry, that was not very clear. Yes you can bind multiple variables already. But you cannot do a disjuction (or) with binding. That would be helpful if you wanted to match patterns like:
> 
> ((x + a) + a)
> or
> (a + (x + a))
> 
> We do that sort of thing a lot in IGVN optimizations: we need to be prepared to iterate over all associative reorderings.

True. There is also no notion of "everyway this pattern can be matched around this center" (even tho, I tried to make patterns deterministic with numbering inputs and picking output of given type).

I think that can fit with Or pattern, and rather for a IGVN use than a checking one. Let's see when we make use of that actually in this context. Then, we will not make stupid blind guesses on how to do it.

>> If you want. I don't think it's perfect because then the message might be less accurate: I don't know that
>>> A CountedLoopEnd is the backedge of a LongCountedLoop.
>> 
>> I rather know that
>>> The backedge of a LongCountedLoop is not a LongCountedLoopEnd
>
> As far as I know, CountedLoopEnd is always the backedge of LongCountedLoop. Same for int. If not, I'd like to see a counter example ;)
> 
> At least this should be true after IGVN.

Don't you mean "LongCountedLoopEnd is always the backedge of LongCountedLoop"? But I rather meant "what if we add another derived class of `CounterLoopEnd`? But I think the new assert should do the trick.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26362#discussion_r2324360017
PR Review Comment: https://git.openjdk.org/jdk/pull/26362#discussion_r2324371124