code optimized away before a deopt

[Gilles Duboscq]

To really understand the problem we would probably need to know exactly
what you (Tom) are trying to achieve and how the snippet is used (lowering?
of which node? when?...).


On Sat, Nov 23, 2013 at 5:23 PM, Doug Simon <doug.simon at oracle.com> wrote:

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