[llvm-dev] Potential missed optimisation with SEH funclets
David Chisnall via llvm-dev
llvm-dev at lists.llvm.org
Thu Jun 27 05:04:56 PDT 2019
A quick skim of this code looks as if we are explicitly disabling frame
pointer elimination for funclets in the back end. It looks as if this
is done because FP-elim sometimes breaks funclets - if anyone has a test
case for this then that would probably help tracking it down.
David
On 26/06/2019 21:17, Reid Kleckner via llvm-dev wrote:
> 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 <mailto: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 <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
More information about the llvm-dev
mailing list