-
Notifications
You must be signed in to change notification settings - Fork 102
Comparing changes
Open a pull request
base repository: rust-lang/llvm-project
base: rustc-1.79.0
head repository: rust-lang/llvm-project
compare: rustc-1.80.0
- 7 commits
- 11 files changed
- 4 contributors
Commits on Jun 30, 2024
-
[AArch64] Avoid overflow when using shl lower mul (llvm#97148)
Fixes llvm#97147. Transforming `(mul x, -(2^(N-M) - 1) * 2^M)` to `(sub (shl x, M), (shl x, N))` will cause overflow when N is 32 and M is 31. I still added checks for all scenarios, even other scenarios, don't seem to cause overflow. (cherry picked from commit 4a96803)
Configuration menu - View commit details
-
Copy full SHA for 934954a - Browse repository at this point
Copy the full SHA 934954aView commit details -
[llvm-config] Make llvm-config --system-libs obey LLVM_USE_STATIC_ZSTD (
llvm#93754) LLVM's build system does the right thing but LLVM_SYSTEM_LIBS ends up containing the shared library. Emit the static library instead when appropriate. With LLVM_USE_STATIC_ZSTD, before: khuey@zhadum:~/dev/llvm-project/build$ ./bin/llvm-config --system-libs -lrt -ldl -lm -lz -lzstd -lxml2 after: khuey@zhadum:~/dev/llvm-project/build$ ./bin/llvm-config --system-libs -lrt -ldl -lm -lz /usr/local/lib/libzstd.a -lxml2 (cherry-picked from 0f24a46)
Configuration menu - View commit details
-
Copy full SHA for e6a6470 - Browse repository at this point
Copy the full SHA e6a6470View commit details
Commits on Jul 5, 2024
-
[X86] var-permute-*.ll - check memory address math
Expose the memory addressing to simplify checking stack spill/restore manipulation codegen (cherry picked from commit 8270485)
Configuration menu - View commit details
-
Copy full SHA for c7d6c06 - Browse repository at this point
Copy the full SHA c7d6c06View commit details -
[X86] matchAddressRecursively - don't fold zext(shl(x,c)) -> shl(zext…
…(x),c)) if the pattern has multiple uses Fixes llvm#97533 crash where we hit a case where the root node had referenced the original zext node, which we then deleted - hopefully I can come up with a better solution, but the codegen changes don't look too bad atm (pulls out a shift from some complex LEA nodes that shared the scaled index). (cherry picked from commit e975ff0)
Configuration menu - View commit details
-
Copy full SHA for 60a1fc8 - Browse repository at this point
Copy the full SHA 60a1fc8View commit details -
[Mem2Reg] Add some single store tests (NFC)
For llvm#97702. (cherry picked from commit e7bfd4d)
Configuration menu - View commit details
-
Copy full SHA for 855a732 - Browse repository at this point
Copy the full SHA 855a732View commit details -
[Mem2Reg] Don't use single store optimization for potentially poison …
…value (llvm#97711) If there is a single store, then loads must either load the stored value or uninitialized memory (undef). If the stored value may be poison, then replacing an uninitialized memory load with it would be incorrect. Fall back to the generic code in that case. This PR only fixes the case where there is a literal poison store -- the case where the value is non-trivially poison will still get miscompiled by phi simplification later, see llvm#96631. Fixes llvm#97702. (cherry picked from commit f58930f)
Configuration menu - View commit details
-
Copy full SHA for 75ec529 - Browse repository at this point
Copy the full SHA 75ec529View commit details -
[Mem2Reg] Always allow single-store optimization for dominating stores
In llvm#97711 the single-store optimization was disabled for the case where the value is potentially poison, as this may produce incorrect results for loads of uninitialized memory. However, this resulted in compile-time regressions. Address these by still allowing the single-store optimization to occur in cases where the store dominates the load, as we know that such a load will always read initialized memory. (cherry picked from commit daaea12)
Configuration menu - View commit details
-
Copy full SHA for c54cff0 - Browse repository at this point
Copy the full SHA c54cff0View commit details
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff rustc-1.79.0...rustc-1.80.0