-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Icky code generated for std::min/std::max #734
Labels
Comments
assigned to @lattner |
Note that the trick to this bug is the whole "when safe" bit. In particular, we -Chris |
Implemented. Patch here: Testcase here: -Chris |
pysuxing
pushed a commit
to pysuxing/llvm-project
that referenced
this issue
Jul 17, 2024
Although currently LowerModule is not ready for formal usage, we need it for target-specific lowering to LLVM. This PR temporarily public the symbol `createLowerModule` to reuse the logic of preparing a `LowerModule`, making it easier for future refactor (making `TargetLoweringInfo` available for most stages in CIR Lowering).
keryell
pushed a commit
to keryell/llvm-project
that referenced
this issue
Oct 19, 2024
Although currently LowerModule is not ready for formal usage, we need it for target-specific lowering to LLVM. This PR temporarily public the symbol `createLowerModule` to reuse the logic of preparing a `LowerModule`, making it easier for future refactor (making `TargetLoweringInfo` available for most stages in CIR Lowering).
xlauko
pushed a commit
to trailofbits/instafix-llvm
that referenced
this issue
Mar 28, 2025
Although currently LowerModule is not ready for formal usage, we need it for target-specific lowering to LLVM. This PR temporarily public the symbol `createLowerModule` to reuse the logic of preparing a `LowerModule`, making it easier for future refactor (making `TargetLoweringInfo` available for most stages in CIR Lowering).
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Extended Description
Consider this C++ testcase:
#include
void test1(int &x, int &y) {
x = std::min(x,y);
}
void test2(int &x, int &y) {
int tmp = x;
y = std::max(tmp,y);
}
We're currently compiling this into:
void %Z5test1RiS(int* %x, int* %y) {
entry:
%tmp.1.i = load int* %y
%tmp.3.i = load int* %x
%tmp.4.i = setlt int %tmp.1.i, %tmp.3.i
%retval.i = select bool %tmp.4.i, int* %y, int* %x
%tmp.4 = load int* %retval.i
store int %tmp.4, int* %x
ret void
}
Note that for this function the %tmp.4 load is redundant with the loads of X or
Y. It would be better to select one of those load's values.
void %Z5test2RiS(int* %x, int* %y) {
entry:
%tmp.0 = alloca int
%tmp.2 = load int* %x
store int %tmp.2, int* %tmp.0
%tmp.3.i = load int* %y
%tmp.4.i = setlt int %tmp.2, %tmp.3.i
%retval.i = select bool %tmp.4.i, int* %y, int* %tmp.0
%tmp.6 = load int* %retval.i
store int %tmp.6, int* %y
ret void
}
This is even worse. Here we are doing the same thing, selecting the address of
Y or the tmp. Because we need it's address, we are not able to register promote
the tmp, leaving it as an alloca. :(
We should transform these selects into selects of the value not of the pointer
when safe.
-Chris
The text was updated successfully, but these errors were encountered: