[llvm-dev] Potential missed optimisation with SEH funclets

[Reid Kleckner via llvm-dev]

Yes, not much effort has been applied to optimizing Windows exception
handling. We were primarily concerned with making it correct, and improving
it hasn't been a priority. You can follow the code path through
X86FrameLowering::emitPrologue with IsFunclet=true and see that it
mechanically emits all the extra instructions mentioned above without any
logic to skip such steps when not necessary.

However, while the mid-level representation we chose makes it hard to write
these types of micro-level code quality optimizations, it allows the
optimizers to do a variety of fancy things like heap to stack promotion on
unique_ptr in the presence of exceptional control flow.

On Tue, Jun 25, 2019 at 4:08 AM Hamza Sood via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I’ve been experimenting with SEH handling in LLVM, and it seems like the
> unwind funclets generated by LLVM are much larger than those generated by
> Microsoft’s CL compiler.
>
> I used the following code as a test:
>
> void test() {
>   MyClass x;
>   externalFunction();
> }
>
> Compiling with CL, the unwind funclet that destroys ‘x’ is just two lines
> of asm:
>
> lea rcx, QWORD PTR x$[rdx]
> jmp ??1MyClass@@QEAA at XZ
>
> However when compiling with clang-cl, it seems like it sets up an entire
> function frame just for the destructor call:
>
> mov qword ptr [rsp + 16], rdx
> push rbp
> .seh_pushreg 5
> sub rsp, 32
> .seh_stackalloc 32
> Lea rbp, [rdx + 48]
> .seh_endprologue
> Lea rcx, [rbp - 16]
> call "??1MyClass@@QEAA at XZ”
> nop
> add rsp, 32
> pop rbp
> ret
>
> Both were compiled with “/c /O2 /MD /EHsc”
>
> Is LLVM missing a major optimisation here?
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190626/3027fb46/attachment.html>