llvm dev - Jan 2015 - [LLVMdev] Why does "uwtable" prevent optimizing Invoke -> Call?

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

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

Hi Björn,

:smiting my forehead: Sure! thats it, thanks a lot.

Alex
> 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

On 2015.01.22 10:42:51 +0100, Björn Steinbrink wrote:
> 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.
I meant to write "either I'm missing something, or clang should always
emit invoke instructions _or_ disabling the optimization was wrong".

Björn

On Thu, Jan 22, 2015 at 4:40 AM, Björn Steinbrink <bsteinbr at gmail.com>
wrote:
> On 2015.01.22 10:42:51 +0100, Björn Steinbrink wrote:
> > 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.
>
> I meant to write "either I'm missing something, or clang should
always
> emit invoke instructions _or_ disabling the optimization was wrong".

I agree, I don't see how uwtable has anything to do with this optimization.
There must be something wrong with our CFI instead.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150122/6d2e9568/attachment.html>

Alexander Poddey wrote:
sorry this one had gone into the wrong thread!
> 
> Hi Björn,
> 
> :smiting my forehead: Sure! thats it, thanks a lot.
> 
> Alex
> 
>> 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