code optimized away before a deopt

[Deneau, Tom]

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.

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
>>>> 
>> 
> 
>