RFR: 8252505: C1/C2 compiler support for blackholes

Aleksey Shipilev shade at openjdk.java.net
Tue Dec 1 08:57:10 UTC 2020


On Wed, 25 Nov 2020 12:42:57 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>>> Modulo the supports_blackholes switch that logic is essentially the same on all platforms, isn't it? Why can you not just fold the relevant case handling into the generated matcher code? Wouldn't that just require a special case switch to decide whether to use the AD file rule to reduce a `CallJavaNode` vs reducing it to nothing?
>> 
>> Is there a guide rail how to do that? Because I cannot see how we can "reduce to nothing" during matching. We still have to match `CallJavaNode` to something, if not to `MachCallJavaNode`. For that, we need `.ad` match rules, AFAICS.
>> 
>> I am exploring if we I can instead do `CallBlackholeNode` as the subclass of `CallJavaNode`, and match it directly. It would also allow ask Matcher if underlying `.ad` supports blackholes by doing `is_match_rule_supported`. It would still add match rules for blackholes to `.ad`-s, but at least it would not need to inject into current match rules.
>
> Even if there are no instructions issued, some of the unfortunate effects of a call may be still there (e.g., spills around the place where the node is scheduled, memory state is effectively killed). Fixing that would involve overriding calling conventions, in_RegMask()/out_RegMask(), customize memory effects.
> 
> Can you elaborate on your experiment with introducing custom node you mentioned? 
> Have you tried introducing new control node and just wire data nodes to it?

Okay, I think I massaged the C2 code to make it much less intrusive. @iwanowww, does it spark joy for you?

Instead of `CallBlackholeJava` node, it is now `CallBlackhole`, the direct descendant of `Call`. It gives us a few improvements: we control how that node is emitted by using its own `CallGenerator` instead of hacking into existing generator, which also absolves us from doing cleanups in `Ideal`. Plus, we can do a few other additions, like `no_reg_save_policy` to avoid grotesque special-casing for new node around register kills, and rather give the node its own special reg save policy.

The only suggestion I failed to follow up on is constructing `MachCallBlackhole` directly in `Matcher`, thus trying to avoid `.ad` changes. I could not find a good place in `Matcher` to do that. I think having a single match rule per `.ad` is still tolerable.

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

PR: https://git.openjdk.java.net/jdk/pull/1203


More information about the hotspot-dev mailing list