code optimized away before a deopt

[Doug Simon]

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