[LLVMdev] Why does "uwtable" prevent optimizing Invoke -> Call?

Mehdi Amini mehdi.amini at apple.com
Thu Jan 22 03:16:03 PST 2015


Hi,

Some context: https://devforums.apple.com/thread/181771
Maybe this one as well: http://llvm.org/bugs/show_bug.cgi?id=15555

OTH,

Mehdi

> On Jan 22, 2015, at 1:42 AM, Björn Steinbrink <bsteinbr at gmail.com> wrote:
> 
> Hi,
> 
> in r176827 the optimization that turns invokes with empty landing pads
> into plain calls was disabled for invocations of function with the
> "uwtable" attribute.
> 
> But given this code:
> 
>    struct S { ~S() {}; };
> 
>    void blackbox();
>    __attribute__((__noinline__)) void inner() { blackbox(); }
> 
>    int foo() {
>        S s;
>        inner();
>        return 0;
>    }
> 
>    int bar() {
>        inner();
>        return 0;
>    }
> 
> clang directly emits a call instruction in "bar", because there is
> nothing to be cleaned up. But in "foo", it emits an invoke instruction
> because of the S object. During optimization, the S object gets
> optimized out and all that remains is the invoke instruction with an
> empty landing pad, causing exception tables to be generated and in some
> cases stopping other optimizations from being applied.
> 
> I don't see why code that has been completely optimized away should have
> an effect on that function call. So AFAICT either I'm missing something
> here, or clang should always emit invoke, disabling the optimization for
> functions that have the uwtable attribute was wrong and the change
> should be reverted.
> 
> FWIW, gcc does not generate exception tables for the above.
> 
> Björn
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev





More information about the llvm-dev mailing list