<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 27, 2015 at 12:29 PM, Kaylor, Andrew <span dir="ltr"><<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div><span class="">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">>In Clang's current IR, what information would you use to size the exception object slot? Currently it looks a bit like this:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">>; 'catch (A e)' where A is an aggregate.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">>%e.addr = alloca %struct.A<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">>...<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">>%ehobj = call i8* @llvm.eh.begincatch(i8* %exn)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">>%ehobj.A = bitcast i8* %ehobj to %struct.A*<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">>call void @A_copy_ctor(%struct.A* %e.addr, %struct.A* %ehobj.A)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">>... ; catch body<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">>call void @A_dtor(%struct.A* %e.addr)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
</span><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.</span></p></div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><span class="">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">>What about this case?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">>void f() {<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">> try {<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">> might_throw();<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">> } catch (int e1) {<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">> try {<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">> might_throw2();<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">> } catch (int e2) {<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">> use_both_exceptions(e1, e2);<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">> }<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">> }<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">>}<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">>I think we need distinct storage for e1 and e2.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
</span><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I suppose you’re right.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.</span></p></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.</span></p></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><span class=""><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">></span> …<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> from a "throw information" table that David is currently looking
at.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
</span><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.</span></p></div></div></blockquote><div><br></div><div>He's just looking at the .xdata tables generated by 'throw', not the catch handler tables.</div></div></div></div>