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

[Vladimir Ivanov]

>> What exactly do you see useful for blackhole inside `if(
>> sfpt->is_Call())` branch? Everything except setting `tf()` looks
>> irrelevant and you can cleanly capture that in MachCallBlackhole
>> factory/ctor.
> 
> It's not that. ADLC actually creates a subclass that defines Name(), 
> rule(), etc.
> 
> We can fake it, but what I am concerned about is introducing a special 
> case for otherwise generic Matcher code. We also basically sidestep DFA 
> machinery, and I am not at all sure what is the effect at subsequent 
> matches for the incoming edges.
> 
> Is there a precedent to create Mach nodes like this? Do we actually know 
> if there are pitfalls? I firmly believe that sticking with what Matcher 
> expects of us: *Node -> Mach*Node rules in .ad -- is safer all around.
> 
> See the example patch:
>    https://cr.openjdk.java.net/~shade/8252505/shared-match.patch

You skipped populating inputs on the MachNode, but I see your point.

> I am not sure I want to trade in a few lines of .ad with fixing new 
> matcher bugs.
> 
>> And don't forget about ADLC changes. Those can also go away / migrate to
>> MachCallBlackhole.
> 
> Yes, they could, but we are drilling another hole in the code that is 
> already quite funky.

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? :-)

Best regards,
Vladimir Ivanov