code optimized away before a deopt

[Tom Rodriguez]

I just pushed a simple assert which should complain when a side effecting node is deleted from a snippet.  http://hg.openjdk.java.net/graal/graal/rev/dbd32c5942e8  I’d be curious if this properly detects the cases that were happening with HSAIL.

tom

On Jun 1, 2014, at 4:06 AM, Gilles Duboscq <duboscq at ssw.jku.at> wrote:

> I think this assert is a good idea.
> In general I don't think you should use deopt in the same way for
> snippets used in lowering in the FLOATING_GUARDS stage and in lowering
> during later stages.
> At the early stages (FLOATING_GUARDS), the deoptimize node intrinsics
> should be used to express guards (which is what the assertion checks)
> and at later stages it's simply a deoptimize node and thus some extra
> logic can be applied before deoptimization.
> Maybe we could use two different intrinsics for these two different usages?
> - deoptimize();
> - Guard g = guard(condition);
> 
> 
> -Gilles
> 
> On Fri, May 30, 2014 at 10:20 PM, Tom Rodriguez
> <tom.rodriguez at oracle.com> wrote:
>> 
>> On May 28, 2014, at 1:47 PM, Deneau, Tom <tom.deneau at amd.com> wrote:
>> 
>>> Dredging up this issue again, I still get burned by it occasionally in our snippets.
>>> The only workaround I have is to insert some test before the actual deopt
>>> and the test has to be something that the compiler can't optimize away.
>>> If I forget such a test, (or if the compiler optimizes it away), the fact
>>> that the side-effecting got discarded can cause situations that are difficult
>>> to debug.
>>> 
>>> Just wondering if anything has happened since Novemeber to make this less error-prone.
>>> I agree with Doug a warning should be the minimum feedback.
>> 
>> I have some changes that assert when a side effecting node is eliminated by ConvertDeoptimizeToGuardPhase during snippet preparation but I have to make some other changes because it’s unhappy about some assertion logic in one of the snippets.  We can see if this assert makes sense in practice.  I guess I was surprised that there weren’t more complaints from existing code but I haven’t run it through the gate yet so maybe there are more.  I’ll push it once I get the assertion issue fixed.
>> 
>> This doesn’t really solve your problem though since it will now complain when something gets eliminated but you still have no way to keep it from being eliminated.  Maybe you could handle it by doing some late lowering to expand the problematic control flow during LOW_TIER lowering?
>> 
>> tom
>> 
>>> 
>>> Or could we have some annotation or something that says in this snippet do not
>>> do the ConvertDeoptimizeToGuardPhase?
>>> 
>>> -- Tom
>>> 
>>> 
>>> 
>>>>> -----Original Message-----
>>>>> From: Doug Simon [mailto:doug.simon at oracle.com]
>>>>> Sent: Saturday, November 23, 2013 10:24 AM
>>>>> To: Lukas Stadler
>>>>> Cc: Deneau, Tom; graal-dev at openjdk.java.net
>>>>> Subject: Re: code optimized away before a deopt
>>>>> 
>>>>> 
>>>>> On Nov 23, 2013, at 5:18 PM, Lukas Stadler <lukas.stadler at jku.at> wrote:
>>>>> 
>>>>>> But it _is_ ok to remove side effecting nodes, because we know they
>>>>> will be reelected.
>>>>> 
>>>>> Yes, normally, but when you write this pattern in a snippet, then
>>>>> this won't be true right, since we don't resume execution in the
>>>>> bytecode of the snippet (yet!). That why I was thinking at least a
>>>>> warning would be a good idea.
>>>>> 
>>>>> -Doug
>>>>> 
>>>>>> Maybe the cleanup operations could be part of a special purpose
>>>>>> deopt
>>>>> node?
>>>>>> 
>>>>>> - Lukas
>>>>>> 
>>>>>> Von meinem iPhone gesendet
>>>>>> 
>>>>>>> Am 23.11.2013 um 16:39 schrieb Doug Simon <doug.simon at oracle.com>:
>>>>>>> 
>>>>>>> This is done by the ConvertDeoptimizeToGuardPhase which replaces
>>>>> conditionals where one branch ends in a deopt with a GuardNode. This
>>>>> does indeed have the side effect of (silently) deleting all other
>>>>> nodes on that deopt-terminated branch. We should add some code to
>>>>> either make the deletion not silent or better, throw an error if
>>>>> these are any side- effecting nodes that will be deleted.
>>>>>>> 
>>>>>>> -Doug
>>>>>>> 
>>>>>>>> On Nov 23, 2013, at 1:58 AM, Deneau, Tom <tom.deneau at amd.com> wrote:
>>>>>>>> 
>>>>>>>> I've noticed that if I have a snippet that does a test and if the
>>>>> test fails, branches to a block that does some cleanup operations and
>>>>> then calls DeoptimizeNode.deopt(xxx, yyy), the cleanup code  gets
>>>>> "optimized away".  I guess this is related to what Gilles was talking
>>>>> about, maybe the cleanup operations were considered not state changing?
>>>>>>>> 
>>>>>>>> In our current state of HSAIL backend, a deopt just returns early
>>>>> from the kernel.   Is there something I can do to make the cleanup code
>>>>> get emitted before the deopt?
>>>>>>>> 
>>>>>>>> -- Tom
>>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>