New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[x86] Failure to remove all statements in function that doesn't return anything but should #46760
Comments
It also seems to completely fail to realise that the code has to be unreachable (unless UB occurs). If I add this code (with int g(bool cond, int a, int b) LLVM is incapable of optimizing this to |
PS: In my second comment, I am not saying that behaviour should be defined where |
Also, here is a Godbolt comparison with GCC (which is capable of optimizing this better than LLVM) : https://godbolt.org/z/Kbs1f1 |
Extra note: This doesn't occur when compiling the code as C (https://godbolt.org/z/n5d65h), so this bug seems even odder now. |
Changing to IR bug - the sooner we can remove dead code, the better (potentially, there's also some clang front-end part of this to account for the C/C++ difference). |
To echo here what was aid in a review [0], we should have a pass early on removing all instructions preceding an unreachable if the are known to transfer control. For the example https://godbolt.org/z/Kbs1f1 , the Attributor knows That said, we might want to have a more localized optimization doing this, and finally land the default |
Should be fixed with more instcombine zapping: Depending on target, we may do better than nothing on UB code as shown in the description. For example, on x86, I see a 'ud2' instruction, so that should crash and make the programmer aware of their buggy code even if they ignore the compile-time warning: |
Extended Description
int f(int a, int b)
{
if ((a < 4 && b == 'r') || (a == 1 && (b == 'h' || b == 'i')) || (a == 2))
a = b;
}
Compiling this results in this assembly output:
f(int, int):
cmp edi, 1
It should be possible to remove the
cmp edi, 1
as far as I know. I guess this isn't really by itself considering the behaviour is undefined anyway but this behaviour itself seems rather weird.The text was updated successfully, but these errors were encountered: