mirror of
https://github.com/RPCS3/llvm.git
synced 2024-12-13 14:47:00 +00:00
46 lines
2.0 KiB
Plaintext
46 lines
2.0 KiB
Plaintext
|
Date: Sat, 19 May 2001 19:09:13 -0500 (CDT)
|
||
|
|
From: Chris Lattner <sabre@nondot.org>
|
||
|
|
To: Vikram S. Adve <vadve@cs.uiuc.edu>
|
||
|
|
Subject: RE: Meeting writeup
|
||
|
|
|
||
|
|
> I read it through and it looks great!
|
||
|
|
|
||
|
|
Thanks!
|
||
|
|
|
||
|
|
> The finally clause in Java may need more thought. The code for this clause
|
||
|
|
> is like a subroutine because it needs to be entered from many points (end of
|
||
|
|
> try block and beginning of each catch block), and then needs to *return to
|
||
|
|
> the place from where the code was entered*. That's why JVM has the
|
||
|
|
> jsr/jsr_w instruction.
|
||
|
|
|
||
|
|
Hrm... I guess that is an implementation decision. It can either be
|
||
|
|
modelled as a subroutine (as java bytecodes do), which is really
|
||
|
|
gross... or it can be modelled as code duplication (emitted once inline,
|
||
|
|
then once in the exception path). Because this could, at worst,
|
||
|
|
slightly less than double the amount of code in a function (it is
|
||
|
|
bounded) I don't think this is a big deal. One of the really nice things
|
||
|
|
about the LLVM representation is that it still allows for runtime code
|
||
|
|
generation for exception paths (exceptions paths are not compiled until
|
||
|
|
needed). Obviously a static compiler couldn't do this though. :)
|
||
|
|
|
||
|
|
In this case, only one copy of the code would be compiled... until the
|
||
|
|
other one is needed on demand. Also this strategy fits with the "zero
|
||
|
|
cost" exception model... the standard case is not burdened with extra
|
||
|
|
branches or "call"s.
|
||
|
|
|
||
|
|
> I suppose you could save the return address in a particular register
|
||
|
|
> (specific to this finally block), jump to the finally block, and then at the
|
||
|
|
> end of the finally block, jump back indirectly through this register. It
|
||
|
|
> will complicate building the CFG but I suppose that can be handled. It is
|
||
|
|
> also unsafe in terms of checking where control returns (which is I suppose
|
||
|
|
> why the JVM doesn't use this).
|
||
|
|
|
||
|
|
I think that a code duplication method would be cleaner, and would avoid
|
||
|
|
the caveats that you mention. Also, it does not slow down the normal case
|
||
|
|
with an indirect branch...
|
||
|
|
|
||
|
|
Like everything, we can probably defer a final decision until later. :)
|
||
|
|
|
||
|
|
-Chris
|
||
|
|
|