EmitDeoptimize, EmitForignCall "createOutOfBoundsException"

[Gilles Duboscq]

For your first question, the profile seems to be the key: this path through
the "create..." foreign call should only appear if profiling shows that
array out of bounds exceptions are actually thrown at this position.
In this case the exception handling is done in the compiled code: it will
create the exception object with that foreign call and the execution will
be diverted to any  catch handler that the compiler could find.

Otherwise, if profile shows that no exception is thrown, the compiler
assumes it can leave the exception handling out. A deoptimization will be
used to go back to the interpreter if that assumption proved to be
incorrect.

A deoptimization is – like a return – a control flow sink, it ends the
execution of the current compilation unit. The foreign call on the other
end is not a control flow sink.
If you replace a foreign call with a return during LIR generation I can see
how later stages such as register allocation can get confused.
In general, it is not a good idea to modify the control flow graph during
LIR generation, many of invariants of the algorithms working on the LIR
will fail.

When compiling for such a target I suppose that you want to stick to
deoptimization to handle cases that are not supported by this execution
environment.
On 2 Jul 2013 20:03, "Tom Deneau" <tom.deneau at amd.com> wrote:

> Here is the background for my visualizer question:
>
> We have a junit test (part of the webrev) called StaticNBodyTest and the
> HSAIL backend is able
> to compile the fairly large run method without problem.
>
> Now to test inlining decisions, I moved the logic to a separate updateBody
> method, and had the
> run method (the target of the compile) call the updateBody method.  By
> default, updateBody has too
> many nodes to be inlined, but I raised the MaximumInliningSize and now
> graal does indeed inline it.
>
> With the inlining completed, the HSAILLirGenerator is now passed several
> emitForeignCall requests
> with the target being "createOutOfBoundsException".  Yet in the original
> StaticNBodyTest (same code,
> just not behind a second layer of method call), there were no
> emitForeignCall requests.
> Instead there were emitDeoptimize requests for the path taken when an
> array index was out of bounds.
>
> Question 1: Why would there be emitDeoptimize in one case, and
> emitForeignCall after inlining?
>
> As a followup question...
>
> We have not decided how to handle exceptions yet in the HSAIL backend, so
> the emitDeoptimize request
> is turned into a request to return early from the HSAIL kernel.   With
> this strategy, code generation
> completes.
>
> However, if I use similar logic with the emitForeignCall request, i.e.
> just generate a return,
> or even just ignore the ForeignCall request completely, I hit the
> following error later in the codegen:
>
> java.lang.AssertionError: using fixed register that is not defined in this
> block
>         at
> com.oracle.graal.compiler.alloc.LinearScan.verifyInput(LinearScan.java:791)
>
> Question 2: Why would this register assertion occur when emitForeignCall
> is replaced by a return, but not when emitDeoptimize
> is similarly replaced by a return?
>
> -- Tom Deneau
>
>
>
>
> -----Original Message-----
> From: graal-dev-bounces at openjdk.java.net [mailto:
> graal-dev-bounces at openjdk.java.net] On Behalf Of Deneau, Tom
> Sent: Tuesday, July 02, 2013 11:53 AM
> To: graal-dev at openjdk.java.net
> Subject: mx igv or mx gv commands
>
> When I try to use
>    mx igv &
>
> as described on the wiki page, I get the splash screen for the visualize
> but then it dies.
> Similarly with mx gv &
>
> Is there some other command that must be run first before using these?
>
> -- Tom
>
>
>
>