[clang] Clang unnecessarily removes code during optimization (regression)

[damiandcoherent]

Putting these lines at the beginning of a function causes clang to remove the entire function. Does not happen if dummy variable inside the if is removed. Can cause strange jumps to other functions. The UB does not cause this in GCC/MSVC.

unsigned A = 32;
unsigned B = 1 << A;
if (B) { unsigned Dummy; }

Clang version: 15+, works fine in clang 14.
Optimization level: -O1 or higher

https://godbolt.org/z/554qxxnbz

[frederick-vs-ja]

Consider this example which unconditionally and explicitly raises UB in main. Clang currently "optimizes" it in the same way as the originally posted example. Godbolt link.

#include <stdio.h>
#include <utility>

int main()
{
    std::unreachable(); // UB!
    puts("Why am I gone?");
}
 
void test()
{
    puts("Why am I here?");
}

I think this is intended. But perhaps some warning would be desired here.

[llvmbot]

@llvm/issue-subscribers-clang-codegen

Author: None (damiandcoherent)

Putting these lines at the beginning of a function causes clang to remove the entire function. Does not happen if dummy variable inside the `if` is removed. Can cause strange jumps to other functions. The UB does not cause this in GCC/MSVC. ``` unsigned A = 32; unsigned B = 1 << A; if (B) { unsigned Dummy; } ```

Clang version: 15+, works fine in clang 14.
Optimization level: -O1 or higher

https://godbolt.org/z/554qxxnbz

[frederick-vs-ja]

This is possibly a duplicate of #130586.

[DavidSpickett]

I notice that different versions of the example would have a warning: https://godbolt.org/z/d49n9jxjT

void no_warning() {
    unsigned A = 32;
    unsigned B = 1 << A;
    (void)B;
}

void const_warning() {
    const unsigned A = 32;
    unsigned B = 1 << A;
    (void)B;
}

void constant_warning() {
    unsigned B = 1 << 32;
    (void)B;
}

Same situation on the other issue?

[damiandcoherent]

Consider this example which unconditionally and explicitly raises UB in main. Clang currently "optimizes" it in the same way as the originally posted example. Godbolt link.

#include <stdio.h>
#include

int main()
{
std::unreachable(); // UB!
puts("Why am I gone?");
}

void test()
{
puts("Why am I here?");
}

I think this is intended. But perhaps some warning would be desired here.

Shouldn't clang consider only the if's body in the original example unreachable, since it is undefined what the value of B is, and thus it can be removed if it is 0 in the implementation? I find it counter-intuitive, that clang "optimizes" the puts call only when the if statement is present.

In your example, it is sensible to remove the puts, since it is hinted to be unreachable.

[DavidSpickett]

If the if is not present, or the body of it is empty and gets removed, there is no branching on poison. Yes there is a poison value there but it has no effect on the program at this optimisation level.

This could also be an example of https://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html "Interacting Compiler Optimizations Lead to Surprising Results". Where if the compiler were to keep the empty if around, it may replace it with unreachable, but if it removes the empty if early enough, it has no reason to generate a branch on a poison value.

So if MSVC and GCC have different pass ordering, that could be the explanation.

[frederick-vs-ja]

See also #144816 for the transformation around the branches.

[shafik]

@frederick-vs-ja we have a broader discussion here: #48943 (comment)

I am trying to keep all these issues linked up, so far I have been linking them up through there. Although maybe there should be a meta issue. This patterns happens around a lot of different undefined behaviors.