`try` block prevents LLVM from identifying a throwing path is unreachable

[jeremy-rifkin]

For the following code LLVM inlines std::vector::at and optimizes away the bounds check

std::vector<int> without_try_catch() {
    std::vector<int> v(10'000);
    for(int i = 0; i < 10'000; ++i) {
        v.at(i) = i;
    }
    return v;
}

However, for the following, the presence of a try/catch precludes LLVM from proving away the bounds check and the subsequent throwing path.

std::vector<int> with_try_catch() {
    std::vector<int> v(10'000);
    for(int i = 0; i < 10'000; ++i) {
        try {
            v.at(i) = i;
        } catch(...) {}
    }
    return v;
}

As a result this dead-code try/catch results in far worse codegen.

CE link: https://godbolt.org/z/e3sT1z4bd

[frederick-vs-ja]

#46035 seems related.

[llvmbot]

@llvm/issue-subscribers-clang-codegen

Author: Jeremy Rifkin (jeremy-rifkin)

For the following code LLVM inlines `std::vector::at` and optimizes away the bounds check ```cpp std::vector<int> without_try_catch() { std::vector<int> v(10'000); for(int i = 0; i < 10'000; ++i) { v.at(i) = i; } return v; } ```

However, for the following, the presence of a try/catch precludes LLVM from proving away the bounds check and the subsequent throwing path.

std::vector<int> with_try_catch() {
    std::vector<int> v(10'000);
    for(int i = 0; i < 10'000; ++i) {
        try {
            v.at(i) = i;
        } catch(...) {}
    }
    return v;
}

As a result this dead-code try/catch results in far worse codegen.

CE link: https://godbolt.org/z/e3sT1z4bd

[efriedma-quic]

-debug-only=gvn says:

GVN: load ptr %0 is clobbered by   %5 = tail call ptr @__cxa_begin_catch(ptr %4) #15

Not sure how it's reaching that conclusion.

The aliasing between the "catch" and the vector ultimately prevents analyzing the vector: we can't prove the vector isn't reallocated by the catch. (It's as if the user wrote something like catch(...) {v = foo();}).

[nikic]

Not sure how it's reaching that conclusion.

This is because we're not treating extractvalue as an escape source. It would make sense to do that as long as CaptureTracking doesn't try to track captures through aggregates.