|
Revision tags: release/13.4.0-p5, release/13.5.0-p1, release/14.2.0-p3, release/13.5.0, release/14.2.0-p2, release/14.1.0-p8, release/13.4.0-p4, release/14.1.0-p7, release/14.2.0-p1, release/13.4.0-p3, release/14.2.0, release/13.4.0 |
|
| #
96ff3348 |
| 28-Jul-2024 |
Dimitry Andric <[email protected]> |
Merge commit c80c09f3e380 from llvm-project (by Dimitry Andric):
[CalcSpillWeights] Avoid x87 excess precision influencing weight result
Fixes #99396
The result of `VirtRegAuxInfo::weightCal
Merge commit c80c09f3e380 from llvm-project (by Dimitry Andric):
[CalcSpillWeights] Avoid x87 excess precision influencing weight result
Fixes #99396
The result of `VirtRegAuxInfo::weightCalcHelper` can be influenced by x87 excess precision, which can result in slightly different register choices when the compiler is hosted on x86_64 or i386. This leads to different object file output when cross-compiling to i386, or native.
Similar to 7af3432e22b0, we need to add a `volatile` qualifier to the local `Weight` variable to force it onto the stack, and avoid the excess precision. Define `stack_float_t` in `MathExtras.h` for this purpose, and use it.
This is the version of the fix for PR276961 that landed upstream.
PR: 276961 Reported by: cperciva MFC after: 3 days
(cherry picked from commit 1a4b8325f6e3a45c77188343da504fe04495cc46)
show more ...
|
| #
51158386 |
| 28-Jul-2024 |
Dimitry Andric <[email protected]> |
Revert "Fix llvm register allocator for native/cross build differences"
In preparation for applying the fix that landed upstream, this reverts commit 397c2693fa66508cb5e6b173650a1f3bc6c4dd4f:
Fix
Revert "Fix llvm register allocator for native/cross build differences"
In preparation for applying the fix that landed upstream, this reverts commit 397c2693fa66508cb5e6b173650a1f3bc6c4dd4f:
Fix llvm register allocator for native/cross build differences
Work around an issue in LLVM's register allocator, which can cause slightly different i386 object files, when produced by a native or cross build of clang.
This adds another volatile qualifier to a float variable declaration in the weightCalcHelper() function, which otherwise produces slightly different float results on amd64 and i386 hosts. In turn, this can lead to different (but equivalent) register choices, and thus non-identical assembly code.
See https://github.com/llvm/llvm-project/issues/99396 for more details.
Note this is a temporary fix, meant to merge in time for 13.4. As soon as upstream has a permanent solution we will import that.
PR: 276961 Reported by: cperciva MFC after: 3 days
(cherry picked from commit 52552d7572a6d3d7d3ce0d6862de9a9d203c5d01)
show more ...
|
| #
2c75d993 |
| 21-Jul-2024 |
Dimitry Andric <[email protected]> |
Fix llvm register allocator for native/cross build differences
Work around an issue in LLVM's register allocator, which can cause slightly different i386 object files, when produced by a native or c
Fix llvm register allocator for native/cross build differences
Work around an issue in LLVM's register allocator, which can cause slightly different i386 object files, when produced by a native or cross build of clang.
This adds another volatile qualifier to a float variable declaration in the weightCalcHelper() function, which otherwise produces slightly different float results on amd64 and i386 hosts. In turn, this can lead to different (but equivalent) register choices, and thus non-identical assembly code.
See https://github.com/llvm/llvm-project/issues/99396 for more details.
Note this is a temporary fix, meant to merge in time for 13.4. As soon as upstream has a permanent solution we will import that.
PR: 276961 Reported by: cperciva MFC after: 3 days
(cherry picked from commit 397c2693fa66508cb5e6b173650a1f3bc6c4dd4f)
show more ...
|
|
Revision tags: release/14.1.0, release/13.3.0 |
|
| #
c9157d92 |
| 18-Dec-2023 |
Dimitry Andric <[email protected]> |
Merge llvm-project main llvmorg-18-init-15088-gd14ee76181fb
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project main llvmorg-18-init-15088-gd14ee76181fb.
Merge llvm-project main llvmorg-18-init-15088-gd14ee76181fb
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project main llvmorg-18-init-15088-gd14ee76181fb.
PR: 276104 MFC after: 1 month
(cherry picked from commit 5f757f3ff9144b609b3c433dfd370cc6bdc191ad)
show more ...
|
|
Revision tags: release/14.0.0 |
|
| #
271697da |
| 11-Sep-2023 |
Dimitry Andric <[email protected]> |
Merge llvm-project release/17.x llvmorg-17.0.0-rc4-10-g0176e8729ea4
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-17.0.0-rc4-10-g0176e8729ea4.
PR: 27375
Merge llvm-project release/17.x llvmorg-17.0.0-rc4-10-g0176e8729ea4
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-17.0.0-rc4-10-g0176e8729ea4.
PR: 273753 MFC after: 1 month
(cherry picked from commit 8a4dda33d67586ca2624f2a38417baa03a533a7f)
show more ...
|
| #
fe013be4 |
| 02-Sep-2023 |
Dimitry Andric <[email protected]> |
Merge llvm-project main llvmorg-17-init-19304-gd0b54bb50e51
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project main llvmorg-17-init-19304-gd0b54bb50e51, t
Merge llvm-project main llvmorg-17-init-19304-gd0b54bb50e51
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project main llvmorg-17-init-19304-gd0b54bb50e51, the last commit before the upstream release/17.x branch was created.
PR: 273753 MFC after: 1 month
(cherry picked from commit 06c3fb2749bda94cb5201f81ffdb8fa6c3161b2e)
show more ...
|
|
Revision tags: release/13.2.0, release/12.4.0, release/13.1.0, release/12.3.0, release/13.0.0, release/12.2.0, release/11.4.0 |
|
| #
0b57cec5 |
| 20-Dec-2019 |
Dimitry Andric <[email protected]> |
Move all sources from the llvm project into contrib/llvm-project.
This uses the new layout of the upstream repository, which was recently migrated to GitHub, and converted into a "monorepo". That i
Move all sources from the llvm project into contrib/llvm-project.
This uses the new layout of the upstream repository, which was recently migrated to GitHub, and converted into a "monorepo". That is, most of the earlier separate sub-projects with their own branches and tags were consolidated into one top-level directory, and are now branched and tagged together.
Updating the vendor area to match this layout is next.
show more ...
|