[PATCH] Make llvm.eh.begincatch use an outparam

Reid Kleckner rnk at google.com
Fri Feb 27 13:16:12 PST 2015


On Fri, Feb 27, 2015 at 12:29 PM, Kaylor, Andrew <andrew.kaylor at intel.com>
wrote:

>  >In Clang's current IR, what information would you use to size the
> exception object slot? Currently it looks a bit like this:
>
> >
>
> >; 'catch (A e)' where A is an aggregate.
>
> >%e.addr = alloca %struct.A
>
> >...
>
> >%ehobj = call i8* @llvm.eh.begincatch(i8* %exn)
>
> >%ehobj.A = bitcast i8* %ehobj to %struct.A*
>
> >call void @A_copy_ctor(%struct.A* %e.addr, %struct.A* %ehobj.A)
>
> >... ; catch body
>
> >call void @A_dtor(%struct.A* %e.addr)
>
>
>
> We could use the bitcast to figure out the size needed.  You’re right that
> the runtime handles the calling of the copy constructor in this case.
>

I wouldn't want to rely on it still being there, especially considering
that we're removing information about pointee types from LLVM soon. In the
outparam scheme, we would strip bitcasts and look for an alloca or
frameallocation and feed that offset into the catch table.

>What about this case?
>
> >
>
> >void f() {
>
> >  try {
>
> >    might_throw();
>
> >  } catch (int e1) {
>
> >    try {
>
> >      might_throw2();
>
> >    } catch (int e2) {
>
> >      use_both_exceptions(e1, e2);
>
> >    }
>
> >  }
>
> >}
>
> >
>
> >I think we need distinct storage for e1 and e2.
>
>
>
> I suppose you’re right.
>
>
>
> I’ve been doing a lot of poking around in the debugger to figure out how
> existing compilers support this stuff.  I don’t know if maybe I’ve been
> inconsistent in the optimization levels I’ve used, but what I’ve seen is
> that the Microsoft compiler has used different stack slots for each catch
> handler in the cases I’ve looked at while the Intel compiler has put
> everything in the same stack slot.  I’ll run your test case above through
> ICC to see what it does.  I’m guessing that it will probably use two
> different stack slots.
>

ICC might just be doing better stack space reuse at -O0 based on source
information about lifetimes. LLVM and MSVC are both kind of bad at this
compared to GCC.


> So, this is leading me to think that maybe your proposed change to
> llvm.eh.begincatch is useful.  Have you talked to John McCall about this?
> As I recall he had some ideas about possibly wanting to use the
> llvm.eh.begincatch intrinsic for non-Windows purposes somewhere down the
> road.
>

I haven't asked, but I'd appreciate his feedback. My gut says that this
change is probably undesirable for alternative C++ EH schemes. A new C++ EH
scheme would probably implicitly pass the pre-adjusted exception pointer to
the catch handler, but allow the code to do the copy and destroy itself.
Representing the copy operation as data in EH tables is exciting. Escaping
the object also means SROA+mem2reg can never promote it.


> > … from a "throw information" table that David is currently looking at.
>
>
>
> Does this mean that David is working on generating the .xdata tables?  If
> so, I’m OK with that.  I’m not sure if I’ve shared everything I know about
> that, but I’ve got extensive notes from research I’ve done to this point.
> I’d be happy to offer assistance.
>
>
>
> On the other hand, if I’m reading too much into the comment, that’s fine
> too.  I’ve actually been planning to do the .xdata table generation myself.
>

He's just looking at the .xdata tables generated by 'throw', not the catch
handler tables.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150227/b4e6df43/attachment.html>


More information about the llvm-commits mailing list