GuardingPiNode, where it can and shouldn't be used

[Miguel Garcia Gutierrez]

> Do your changes require GuardingPiNode to be a GuardingNode?

I was relying on that but in a non-essential manner, there should be an alternative. The scenario in question revolves around lowering CheckCastNode. However, any lowering producing a (fixed) GuardingNode will do. I'll get back to that soon, in the meantime I'm fixing one or two bugs that preclude benchmarking.


Miguel

----- Original Message -----
From: lukas.stadler at oracle.com
To: miguel.m.garcia at oracle.com
Cc: graal-dev at openjdk.java.net
Sent: Tuesday, April 8, 2014 4:40:25 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: GuardingPiNode, where it can and shouldn't be used

That would mean that every user of a GuardingNode always has to check for these flags, that seems rather complicated.

The GuardingPiNode shouldn’t be a GuardingNode (I actually removed the interface yesterday), at least not as it is implemented at the moment.
Using the replaceAtUsage with InputType, we can implement it correctly.

Do your changes require GuardingPiNode to be a GuardingNode?

- Lukas

On 08 Apr 2014, at 16:09, Miguel Garcia Gutierrez <miguel.m.garcia at oracle.com> wrote:

> 
> (Lukas, perhaps you forgot to also reply to graal-dev, only I received your reply.)
> 
> Thanks for the heads-up, the distinction that InputType enables is indeed useful.
> 
> Thinking ahead, perhaps the right place to canonicalize a GuardingNode isn't at the definition site. How about if GuardingNode were defined as:
> 
> public interface GuardingNode {
> 
>    ValueNode asNode();
> 
>    boolean alwaysSucceeds();
> 
>    boolean alwaysFails();
> }
> 
> That way, a node using a guard might check whether it alwaysSucceeds(), and if so lift the scheduling restriction.
> 
> 
> Miguel
> 
> 
> 
> ----- Original Message -----
> From: lukas.stadler at oracle.com
> To: miguel.m.garcia at oracle.com
> Sent: Tuesday, April 8, 2014 9:05:19 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
> Subject: Re: GuardingPiNode, where it can and shouldn't be used
> 
> There’s a new facility to specify types for inputs that I pushed yesterday.
> This would allow the canonicalization of GuardingPiNode to replace itself with different nodes for different input types, like this:
> replaceAtUsages(InputType.Guard, …);
> replaceAtUsages(InputType.Value, …);
> 
> Of course, this doesn’t work for canonicalize, but only for simplify.
> In my opinion, it’s debatable if the GuardingPiNode should even be a GuardingNode.
> 
> - Lukas
> 
> On 07 Apr 2014, at 13:26, Miguel Garcia Gutierrez <miguel.m.garcia at oracle.com> wrote:
> 
>> 
>> I have a philosophical question about GuardingPiNode, in connection with its canonicalization.
>> 
>> GuardingPiNode is a GuardingNode, and as such a GuardingPiNode instance may be given as the guard of a PiNode.
>> 
>> A prototype I'm working on runs into the situation where:
>> (a) a GuardingPiNode is canonicalized (as expected) upon its condition becoming a constant
>> (b) as a consequence, the payload of the GuardingPiNode (ie the canonical value) is replaced at all usages of the GuardingPiNode (also as expected)
>> 
>> That's all fine, and fits the pattern where such usages were expecting the payload that the GuardingPiNode wraps.
>> 
>> However, coming back to the example of the PiNode taking a GuardingPiNode instance as guard-input and not as object-input.
>> 
>> Applying (a) and (b) in that case results in attempting to assign the payload to the PiNode's guard, which in general results in ClassCastException (the payload in general doesn't implement GuardingNode).
>> 
>> I can think of some workarounds. Is there anything like a general solution?
>> 
>> 
>> Miguel
>> 
>