code optimized away before a deopt

[Lukas Stadler]

But it _is_ ok to remove side effecting nodes, because we know they will be reexecuted.
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
>