Merge LLVM branch release/17.x into rustc/17.0-2023-07-29
#152
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Differential Revision: https://reviews.llvm.org/D157630 (cherry picked from commit 2df9ed1)
…e multiple reductions. When a loop has multiple reductions, each with an intermediate invariant store, the order in which those reductions are processed is not considered. This can result in the invariant stores outside the loop not preserving the original order. This patch sorts VPReductionPHIRecipes by the order in which they have stores in the original loop before running `InnerLoopVectorizer::fixReduction` function, and it helps to maintain the correct order of stores. Fixes llvm#64047 Differential Revision: https://reviews.llvm.org/D157631 (cherry picked from commit ac65fb8)
…safe mode This patch effectively maintains the status quo, making sure that the safe mode keeps working the same way as before. Hardening will target the next major release, allowing it to go through RFC and for the implementation to stabilize and mature. Differential Revision: https://reviews.llvm.org/D159171
(cherry picked from commit 2fce8f7)
… in ComplexDeinterleavingPass When replacing ComplexDeinterleavingPass::ReductionOperation, we can do it either from the Real or Imaginary part. The correct way is to take whichever is later in the BasicBlock, but before the patch, we just always took the Real part. Fixes llvm#65044 Differential Revision: https://reviews.llvm.org/D159209 (cherry picked from commit e2cb07c)
The following commit enabled the analysis of ranges for heap allocations: 22ca38d The range turns out to be empty in cases such as the one in test (which is [1,1)), leading to an assertion failure. This patch fixes for the same case. Fixes llvm#63856 Reviewed By: fhahn Differential Revision: https://reviews.llvm.org/D159160 (cherry picked from commit 0609b65)
Whilst Clang does not use these, recent GCC does, and so on systems such as FreeBSD that wish to use compiler-rt as the system runtime library but also wish to support building programs with GCC these interfaces are needed. This is a light adaptation of the code committed to GCC by Sebastian Pop <[email protected]>, relicensed with permission for use in compiler-rt. Fixes llvm#63483 Reviewed By: sebpop, MaskRay Differential Revision: https://reviews.llvm.org/D158536 (cherry picked from commit 4bb2416)
As reported by mgorny at https://reviews.llvm.org/D159115#4638037, the unsigned long long cast fails on 32-bit systems at least with GCC. It looks like a pointer provenance/aliasing issue rather than a bug in GCC. Acked by Vassil Vassilev on the original revision. (cherry picked from commit 3403686)
This patch enables the Fortran runtime support library to be built without native 128-bit integer support in the C++ compiler. Experimental: do not merge yet. Differential Revision: https://reviews.llvm.org/D154660 (cherry picked from commit 1c35c1a)
This removes the backend requirement for crc instructions on HasV8, relying on just HasCRC instead. This should allow them to be selected with ArmV7 + crc, making them more usable whilst hopefully not making them incorrectly generated (they only come from intrinsics, and HasCRC usually requires HasV8). This is how most other instructions are specified. (cherry picked from commit a82c106)
…orting them The trick we use (since cbc2a06) for exporting the __chkstk function (with various per-arch names) that is defined in a different object file, relies on the function already being linked in (by some function referencing it). This function does end up referenced if there's a function that allocates more than 4 KB on the stack. In most cases, it's referenced somewhere, but in the case of builds with LLVM_LINK_LLVM_DYLIB enabled (so most of the code resides in a separate libLLVM-<ver>.dll) the only code in lli.exe is the lli tool specific code and the mingw-w64 crt startup code. In the case of GCC based MinGW i386 builds with LLVM_LINK_LLVM_DYLIB, nothing else references it though. Manually add a reference to the function to make sure it is linked in (from libgcc or compiler-rt builtins) so that it can be exported. This fixes one build issue encountered in msys2/MINGW-packages#18002. Differential Revision: https://reviews.llvm.org/D159085 (cherry picked from commit 4bba12f)
(cherry picked from commit fef8249)
…ay bring regressions" This reverts commit 6998ecd.
…aiter is not empty" This reverts commit f05226d.
|
Closing this; the final 17.0 release should be cut tomorrow so I'll file an update from that tag. |
|
Note, we usually do a clean rebase after the final release, so that will go into a new branch. A PR won't work for that. |
|
That makes sense, I was wondering if that would be the case. I'd be happy to help out with the rebase if possible! |
vext01
pushed a commit
to vext01/llvm-project
that referenced
this pull request
May 10, 2024
Yk serialiser: Handle dynamic indexing in getelementptr instructions.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This updates the version of LLVM 17 to the latest release branch upstream (the branch is currently at
llvmorg-17.0.0-rc4). Motivated by this fix for this issue.