instanceof code and OptimizedTypeCheckViolated

[Deneau, Tom]

When I use the -Dgraal.traceMethodDataFilter=class.method
flag, I see that the times it is failing, the branchData is
50-50, but when it is succeeding, it is like there is no profile info at all
(unless I am reading this incorrectly).  Why would there be no profile data?
For example...

Raw method data for com.oracle.graal.compiler.hsail.test.lambda.InstanceOfTest.lambda$runTest$4(int):
0      bci: 11    TypeCheckData       count(0) null_seen(FALSE) exception_seen(FALSE) nonprofiled_count(0) entries(0)
56     bci: 14    BranchData          taken(0, -1.00) not_taken(0, 2.00) displacement(56)
88     bci: 18    JumpData            taken(0) displacement(24)


vs. other times seeing

0      bci: 11    TypeCheckData       count(2147483647) null_seen(FALSE) exception_seen(FALSE) nonprofiled_count(0) entries(1)
                                        com.oracle.graal.compiler.hsail.test.lambda.VirtualCallTest$Circle (10, 1.00)
56     bci: 14    BranchData          taken(10, 0.50) not_taken(10, 0.50) displacement(56)
88     bci: 18    JumpData            taken(10) displacement(24)

-- Tom


> -----Original Message-----
> From: Doug Simon [mailto:doug.simon at oracle.com]
> Sent: Monday, January 27, 2014 3:45 PM
> To: Tom Rodriguez
> Cc: Deneau, Tom; graal-dev at openjdk.java.net
> Subject: Re: instanceof code and OptimizedTypeCheckViolated
> 
> 
> On Jan 27, 2014, at 10:37 PM, Tom Rodriguez <tom.rodriguez at oracle.com>
> wrote:
> 
> > It's probably some minor difference in the profile.  You can use -
> Dgraal.traceMethodDataFilter=class.method to dump the method data used
> for that method.  In general I would think for GPU we'd want to avoid
> any overly optimistic profile based optimization since deopt is likely
> to be hugely expensive for GPU or at least a waste of compute resources.
> TypeCheckMinProfileHitProbability appears to control this code, so you
> might try overriding it with a higher value.
> >
> > I'm actually unclear under what conditions instanceofWithProfile will
> win over a straight instance of test.  Maybe interface types or deep
> hierarchies?
> 
> Definitely over these latter cases as not only will the generated code
> be tighter, but types after the instanceof node in the graph could
> potentially be much tighter. There maybe idiomatic Truffle code where
> this is particularly true?
> 
> -Doug
> 
> > On Jan 27, 2014, at 12:59 PM, Deneau, Tom <tom.deneau at amd.com> wrote:
> >
> >> Question on some instanceof codegen in one of our hsail junits
> >>
> >> Java code is:
> >>
> >>   float[] outArray;
> >>   Shape[] inShapeArray;
> >> (gid)->{
> >>     outArray[gid] = (inShapeArray[gid] instanceof Circle ? 1.0f :
> >> 2.0f);  });
> >>
> >> The inShapeArray is 50/50 Circle and non-Circle (and we have executed
> >> as java first so have some profiling)
> >>
> >> Yet the generated code is taking a deopt path for reason
> OptimizedTypeCheckViolated when it is not a circle.
> >> So the code to store 2.0 is never generated.
> >>
> >> In igv, I can see that this happens when we inline
> >> InstanceOfSnippets.instanceofWithProfile
> >>
> >> This doesn't happen on every codegen, sometimes the 2.0 store block
> is generated nicely.
> >>
> >> This used to work fine until I think a few weeks ago...
> >>
> >> Any suggestions?
> >>
> >> -- Tom
> >>
> >>
> >> @L7:
> >> 	ld_global_u32 $d0, [$d0 + 8];
> >> 	shl_u64 $d0, $d0, 3;
> >> 	mov_b64 $d2, 0x1000fcd88;                  // check if class ==
> Circle
> >> 	cmp_ne_b1_s64 $c0, $d2, $d0;
> >> 	cbr $c0, @L11;
> >> @L8:
> >> 	ld_global_s32 $s1, [$d1 + 12];
> >> 	cmp_ge_b1_u32 $c0, $s0, $s1;
> >> 	cbr $c0, @L10;
> >> @L9:
> >> 	cvt_s64_s32 $d0, $s0;                      // code that stores
> 1.0f for Circle case
> >> 	mul_s64 $d0, $d0, 4;
> >> 	add_u64 $d1, $d1, $d0;
> >> 	mov_b32 $s0, 1.0f;
> >> 	st_global_f32 $s0, [$d1 + 16];
> >> 	ret;
> >> @L1:
> >> 	mov_b32 $s0, -21259;
> >> @L13:
> >> 	ret;
> >> @L11:
> >>     // not a Circle, deoptimize with OptimizedTypeCheckViolated
> >> reason
> >>
> >
>