[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