RFR: 8252505: C1/C2 compiler support for blackholes [v11]

[Vladimir Ivanov]

>> I have a better example for you: MemBarCPUOrder doesn't participate in
>> matching at all (I'll save you some time: it signals `Matcher` to ignore
>> it through `ideal_reg() == 0` which is taken into account by
>> `Matcher::is_dontcare()`/`Matcher::find_shared_visit()`), but still does
>> its job in Mach IR. The only thing it misses to satisfy blackhole
>> requirements is it doesn't keep anything alive. But it seems just adding
>> the `in_RegMask()` you have should be enough to get you there. And then
>> you can get rid of any ADLC, Matcher, and CallNode-related changes you
>> have right now. It seems, no drilling needed, right? :-)
> 
> I think being explicit about Blackhole having a call-like effects, 
> having its own call generators, and matching as any regular node is the 
> explicitness that is good explicitness. Yes, it adds a handful of LOCs 
> on regular paths, but it does not try to do many special things at once. 
> This is why CallBlackholeJava -> CallBlackhole remodel happened: making 
> it less special and more congruent with existing nodes, even though it 
> would have been "easier" to hack the Call*Java.
> 
> We need to draw the line in the sand somewhere. I can try to do what 
> MemBarCPUOrder does, but honestly it feels like a conceptual step back.

That's the point we disagree on from the very beginning.

For me, modeling a Blackhole-like entity with a call node is far from a 
perfect match from conceptual perspective. From engineering perspective 
it may be convenient and simplify some implementation aspects, but it 
brings a lot of baggage which is completely unrelated to the final goal.

As I pointed out earlier in our discussion, there are other concepts 
(like SafePoint and MemBar) in C2 which aren't a perfect fit as well, 
but in many respects a closer match to model Blackhole.

I think we have much better understanding now what is essential for 
Blackhole and it can be implemented with something simple yet sufficient 
to do the job.

In that respect, lowering to Mach IR is completely irrelevant: Blackhole 
doesn't require anything platform-specific.

Blackhole doesn't need anything more than control and memory ordering 
effects from a Call (plus, some rudimentary argument support), so either 
the rest of the functionality has to be explicitly undone/disabled or in 
the best case left intact unused.

Also, I consider Blackhole a very niche tool and it feels much closer to 
yet another intrinsic (which routinely inject custom nodes and IR shapes 
into the graph) than a CallGenerator which IMO is more appropriate to 
represent call strategies than just a factory to construct call nodes. 
(FTR it's perfectly fine to produce calls in intrinsics. And the the 
peculiarities of constructing Blackhole node can be encapsulated inside 
GraphKit/LibraryCallKit.)

Initially, the major obstacle to adopt intrinsics was the requirement on 
them to be placed only in trusted code inside JDK, but I think we have 
the answer now how to relax the limitation.

That's my take on the problem you are trying to solve.

> The next thing you would ask is to print consumed values in 
> OptoAssembly, like I am prototyping now for MachCallBlackhole. It is 
> possible now because Matcher knows about it and its form. If Matcher 
> ignores MemBarCPUOrder, does it mean OptoAssembly omits any format for 
> it as well?

It's not Matcher job. It's ADLC which pre-generates the implementation 
from a pattern described in format section.

The nodes ignored during matching aren't removed, but stays intact in 
the graph surrounded by newly created mach nodes. (Otherwise, 
MemBarCPUOrder wouldn't have been able to succeed at its job of ordering 
the memory graph.)

PrintOptoAssembly just iterates over scheduled Mach IR at the end of 
PhaseOutput and calls `Node::format()` on each node (with some 
exceptions). So, if a node is part of Mach IR, then it is visited.

You can easily customize the output by overriding 
`Node::format(PhaseRegAlloc*)` and some ideal nodes already do that 
(e.g., BoxLock).

Best regards,
Vladimir Ivanov