<div dir="ltr">The main reason it is done is so that frame index resolution just works inside funclets. Otherwise, we'd have to code up some logic to use a different base register for stack object offsets inside funclets. Which, when you say it that way, seems pretty easy to implement. It's just a matter of changing X86FrameLowering::getFrameIndexReference.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 27, 2019 at 5:05 AM David Chisnall via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">A quick skim of this code looks as if we are explicitly disabling frame <br>
pointer elimination for funclets in the back end.  It looks as if this <br>
is done because FP-elim sometimes breaks funclets - if anyone has a test <br>
case for this then that would probably help tracking it down.<br>
<br>
David<br>
<br>
On 26/06/2019 21:17, Reid Kleckner via llvm-dev wrote:<br>
> Yes, not much effort has been applied to optimizing Windows exception <br>
> handling. We were primarily concerned with making it correct, and <br>
> improving it hasn't been a priority. You can follow the code path <br>
> through X86FrameLowering::emitPrologue with IsFunclet=true and see that <br>
> it mechanically emits all the extra instructions mentioned above without <br>
> any logic to skip such steps when not necessary.<br>
> <br>
> However, while the mid-level representation we chose makes it hard to <br>
> write these types of micro-level code quality optimizations, it allows <br>
> the optimizers to do a variety of fancy things like heap to stack <br>
> promotion on unique_ptr in the presence of exceptional control flow.<br>
> <br>
> On Tue, Jun 25, 2019 at 4:08 AM Hamza Sood via llvm-dev <br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>> wrote:<br>
> <br>
>     I’ve been experimenting with SEH handling in LLVM, and it seems like<br>
>     the unwind funclets generated by LLVM are much larger than those<br>
>     generated by Microsoft’s CL compiler.<br>
> <br>
>     I used the following code as a test:<br>
> <br>
>     void test() {<br>
>        MyClass x;<br>
>        externalFunction();<br>
>     }<br>
> <br>
>     Compiling with CL, the unwind funclet that destroys ‘x’ is just two<br>
>     lines of asm:<br>
> <br>
>     lea rcx, QWORD PTR x$[rdx]<br>
>     jmp ??1MyClass@@QEAA@XZ<br>
> <br>
>     However when compiling with clang-cl, it seems like it sets up an<br>
>     entire function frame just for the destructor call:<br>
> <br>
>     mov qword ptr [rsp + 16], rdx<br>
>     push rbp<br>
>     .seh_pushreg 5<br>
>     sub rsp, 32<br>
>     .seh_stackalloc 32<br>
>     Lea rbp, [rdx + 48]<br>
>     .seh_endprologue<br>
>     Lea rcx, [rbp - 16]<br>
>     call "??1MyClass@@QEAA@XZ”<br>
>     nop<br>
>     add rsp, 32<br>
>     pop rbp<br>
>     ret<br>
> <br>
>     Both were compiled with “/c /O2 /MD /EHsc”<br>
> <br>
>     Is LLVM missing a major optimisation here?<br>
>     _______________________________________________<br>
>     LLVM Developers mailing list<br>
>     <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
>     <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> <br>
> <br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> <br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>