[LLVMdev] Inlining and exception handling in LLVM and GCC

Renato Golin rengolin at systemcall.org
Tue Dec 7 03:54:37 PST 2010


Hi Duncan,

Amazing post, thank you very much!

Now I have a clear mental image of the whole problem and can see where
you were coming from to propose such a change.


On 6 December 2010 21:58, Duncan Sands <baldrick at free.fr> wrote:
> Bill's recent exception handling proposal has rules which (if I understand
> them right) ensure that you can always find the actions for an invoke without
> any trouble (the actions would be listed in a dispatch instruction that is
> not allowed to be moved out of the landing pad).  Thus with this proposal too
> there would also be no problem in teaching the inliner to do the right thing.

If I got it right, you're saying that both proposals are similar in
that they both fix the inlining problem and both specify uniquely the
landing pads for every invoke.

So, in view of their equivalence, I think Bill's proposal is better
for two reasons:

  1. It eases the future elimination of invoke, or at least, the
treatment of current instruction-level exception (as in Java) in a
cleaner way.
  2. It reinforces the idea of having one personality function for
each EH table (ie. per function), especially when inlining code from
different paradigms (if that's possible).

However, your proposal is better in two other accounts:

  1. If we do want to support EH tables with multiple personalities in
the future.
  2. It's less invasive and closer to the problem it meant to fix in
the first place. So it'll be faster and easier to do that way.


It's more of a design decision, IMO.


-- 
cheers,
--renato

http://systemcall.org/

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm




More information about the llvm-dev mailing list