conditional move

[Deneau, Tom]

I have confirmed that if this restriction in IfNode is commented out, we do in the HSAIL backend generate conditional moves for the float code using constants below.

Restricting to constants might be too strict, I can imagine cases where the alternatives are not constants but have already been calculated so no additional  work is needed.  Or as Gilles said perhaps in all cases the backend should decide whether any additional work outweighs the benefit of the conditional move (or more pessimistically the penalty of the branch).

-- Tom

-----Original Message-----
From: Lukas Stadler [mailto:lukas.stadler at jku.at] 
Sent: Wednesday, June 19, 2013 8:20 AM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net
Subject: Re: conditional move

There's a heuristic in the canonicalization of IfNodes that says that it is only beneficial to create a ConditionalNode if the two values are constant integers or constant longs.
You can see it in IfNode.removeOrMaterializeIf. This restriction on types is AMD64 - specific, and I think we should remove it anyway.
(because the only downside could be that we have to create the if again at a lower level).

The restriction on constants, however, makes sense - because if we need to do work to calculate the values then this work should happen only if we need it.

- Lukas

On Jun 19, 2013, at 3:07 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> Wondering whether anyone knows the reason for the problem below?
> For the HSAIL backend, we would like both to emit conditional moves.
> Is there a backend property that enables this?
> 
> -- Tom
> 
> 
> -----Original Message-----
> From: Deneau, Tom 
> Sent: Friday, May 24, 2013 6:42 PM
> To: 'Doug Simon'; Frost, Gary
> Cc: Lukas Stadler; graal-dev at openjdk.java.net
> Subject: RE: conditional move
> 
> I noticed that this code emits a Conditional Move node
> 
> 	public int test(int a, int b) {
> 		return (a < b ? 1 : 2);
> 	}
> 
> but this one does not
> 	public float test(int a, int b) {
> 		return (a < b ? 1.0f : 2.0f);
> 	}
> 
> -- Tom
> 
> -----Original Message-----
> From: Doug Simon [mailto:doug.simon at oracle.com] 
> Sent: Friday, May 24, 2013 10:28 AM
> To: Frost, Gary
> Cc: Lukas Stadler; Deneau, Tom; graal-dev at openjdk.java.net
> Subject: Re: conditional move
> 
> Yes, because ternaries are compiled by javac as if-statements.
> 
> On May 24, 2013, at 5:17 PM, "Frost, Gary" <Gary.Frost at amd.com> wrote:
> 
>> Presumably, ternaries are good candidates for this. 
>> 
>> boolean isOdd(int i){
>>   boolean odd=((i%2)!=0)?0:1;
>>   return odd;
>> }
>> 
>> -----Original Message-----
>> From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Lukas Stadler
>> Sent: Friday, May 24, 2013 3:51 AM
>> To: Deneau, Tom
>> Cc: graal-dev at openjdk.java.net
>> Subject: Re: conditional move
>> 
>> The ConditionalNode is most of the time not created by the GraphBuilder directly, but it will appear later when a simple if/then/else is canonicalized.
>> So a simple snippet that boils down to a conditional move could look like this:
>> 
>> public static int testSnippet(int i) {
>> if (i == 0) {
>>   return 1;
>> } else {
>>   return 2;
>> }
>> }
>> 
>> - Lukas
>> 
>> 
>> On May 24, 2013, at 1:04 AM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
>> 
>>> While compiling a larger chunk of code we were handed a 
>>> ConditionalMove node (which we have not implemented yet).  I would 
>>> like to make a smaller test case for this but java patterns that I 
>>> thought would be mapping to conditional move aren't doing so.  What 
>>> would be a typical small test case for generating the ConditionalMove node?
>>> 
>>> -- Tom Deneau
>>> 
>> 
>> 
>> 
> 
> 
>