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

[Aleksey Shipilev]

On 12/2/20 6:10 PM, Vladimir Ivanov wrote:
> 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.

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?

-- 
Thanks,
-Aleksey