[tree-ssa] Gimplifying jsr

[Eric Blake]

By the way, Sun is considering deprecating jsr and return in their JDK 
1.5 release (and also the JLS 3rd version to be published at that time). 
  There are demonstratable cases of legal Java code according to the JLS 
that cannot pass verification according to the JVMS when the compiler 
uses jsr.  Sun's suggested replacement is to always inline finally 
statements at all points where they could be invoked.

http://developer.java.sun.com/developer/bugParade/bugs/4381996.html

Andrew Haley wrote:
> The Java VM has jsr and ret instructions.  These are traditionally
> used for FINALLY, but they may be used for any purpose.  This is what
> they do:
> 
> 
> jsr 
> 
> The address of the opcode of the instruction immediately following
> this jsr instruction is [saved].  Execution proceeds at [some] offset
> from the address of this jsr instruction
> 
> 
> ret
> 
> The local variable at index in the current frame (§3.6) must contain a
> value of type returnAddress. The contents of the local variable are
> written into the Java virtual machine's pc register, and execution
> continues there.
> 
> 
> So, you have a subroutine call within a function.  gcj does this:
> 
> 	move L2 -> tmp
> 	jmp L1
> L2:
> 
> 	...
> 
> L1:
> 	...
> 	jmp (tmp)
> 
> but I'm not sure how to convert this to GENERIC.  If it just-so
> happens that the target of the jsr is laid out in a convenient way, we
> can generate a TRY...FINALLY.  Or maybe we can copy the instructions
> to the point of call, as long as there is no branch out of the target
> of the jsr.  
> 
> I'm pretty sure we can't use a goto, because the subroutine is within
> the same lexical scope as the point from which it was called, and can
> modify global variables there.
> 
> Hmm.  Thoughts welcome.
> 
> Andrew.
> 
> 
> 
>