[all-commits] [llvm/llvm-project] 9672d1: [MLIR][Presburger] Disambiguate call to floor
rorth via All-commits
all-commits at lists.llvm.org
Tue Feb 22 11:19:20 PST 2022
Branch: refs/heads/release/14.x
Home: https://github.com/llvm/llvm-project
Commit: 9672d11441fd619d419554fee2ce006053d1d937
https://github.com/llvm/llvm-project/commit/9672d11441fd619d419554fee2ce006053d1d937
Author: Rainer Orth <ro at CeBiTec.Uni-Bielefeld.DE>
Date: 2022-02-22 (Tue, 22 Feb 2022)
Changed paths:
M mlir/lib/Analysis/Presburger/Utils.cpp
Log Message:
-----------
[MLIR][Presburger] Disambiguate call to floor
While testing LLVM 14.0.0 rc1 on Solaris, compilation of `FAIL`ed with
/var/llvm/llvm-14.0.0-rc1/rc1/llvm-project/mlir/lib/Analysis/Presburger/Utils.cpp: In lambda function:
/var/llvm/llvm-14.0.0-rc1/rc1/llvm-project/mlir/lib/Analysis/Presburger/Utils.cpp:48:58: error: call of overloaded ‘floor(int64_t)’ is ambiguous
48 | [gcd](int64_t &n) { return floor(n / gcd); });
| ^
...
/usr/gcc/10/lib/gcc/sparcv9-sun-solaris2.11/10.3.0/include-fixed/iso/math_iso.h:201:21:
note: candidate: ‘long double std::floor(long double)’
201 | inline long double floor(long double __X) { return __floorl(__X); }
| ^~~~~
/usr/gcc/10/lib/gcc/sparcv9-sun-solaris2.11/10.3.0/include-fixed/iso/math_iso.h:165:15:
note: candidate: ‘float std::floor(float)’
165 | inline float floor(float __X) { return __floorf(__X); }
| ^~~~~
/usr/gcc/10/lib/gcc/sparcv9-sun-solaris2.11/10.3.0/include-fixed/iso/math_iso.h:78:15:
note: candidate: ‘double std::floor(double)’
78 | extern double floor __P((double));
| ^~~~~
The same issue had already occured in the past, cf. D108750
<https://reviews.llvm.org/D108750>, and the solution is the same: cast the
`floor` arg to `double`.
Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D119324
(cherry picked from commit 91596755359e29c677bfa84d86edcaa1e70df955)
Commit: 3367c24735c3408517c6088061eee39030a69e70
https://github.com/llvm/llvm-project/commit/3367c24735c3408517c6088061eee39030a69e70
Author: Nicolas Miller <nicolas.miller at codeplay.com>
Date: 2022-02-22 (Tue, 22 Feb 2022)
Changed paths:
M llvm/include/llvm/BinaryFormat/COFF.h
M llvm/lib/BinaryFormat/CMakeLists.txt
A llvm/lib/BinaryFormat/COFF.cpp
M llvm/lib/MC/WinCOFFObjectWriter.cpp
Log Message:
-----------
[COFF] Move section name encoding into BinaryFormat
Large COFF section names are moved into the string table and the
section header field is the offset into the string table encoded in
ASCII for offset smaller than 7 digits and in base64 for larger
offsets.
The operation of taking the string table offsets is done in a few
places in the codebase, so it is helpful to move this operation into
`BinaryFormat` so that it can be shared everywhere it's done.
So this patch takes the implementation of this operation from
`llvm/lib/MC/WinCOFFObjectWriter.cpp` and moves it into `BinaryFormat`.
Reviewed By: jhenderson, rnk
Differential Revision: https://reviews.llvm.org/D118793
(cherry picked from commit 85f4023e731c0c42e45bf32bfcbf5f73c2013384)
Commit: cefe6876d6e55ee8d544ab98216251ddd35ee7a9
https://github.com/llvm/llvm-project/commit/cefe6876d6e55ee8d544ab98216251ddd35ee7a9
Author: Nicolas Miller <nicolas.miller at codeplay.com>
Date: 2022-02-22 (Tue, 22 Feb 2022)
Changed paths:
A llvm/test/tools/llvm-objcopy/COFF/section-name-encoding.s
M llvm/tools/llvm-objcopy/CMakeLists.txt
M llvm/tools/llvm-objcopy/COFF/Writer.cpp
M llvm/tools/llvm-objcopy/COFF/Writer.h
Log Message:
-----------
[llvm-objcopy][COFF] Fix section name encoding
The section name encoding for `llvm-objcopy` had two main issues, the
first is that the size used for the `snprintf` in the original code is
incorrect because `snprintf` adds a null byte, so this code was only
able to encode offsets of 6 digits - `/`, `\0` and 6 digits of the
offset - rather than the 7 digits it should support.
And the second part is that it didn't support the base64 encoding for
offsets larger than 7 digits.
This issue specifically showed up when using the `clang-offload-bundler`
with a binary containing a lot of symbols/sections, since it uses
`llvm-objcopy` to add the sections containing the offload code.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D118692
(cherry picked from commit ddf528b7a092fd24647d7c6186ece7392c92de92)
Commit: 88f8980a4d95b16a0dcd57bb6da298d4d60d8fd1
https://github.com/llvm/llvm-project/commit/88f8980a4d95b16a0dcd57bb6da298d4d60d8fd1
Author: Kerry McLaughlin <kerry.mclaughlin at arm.com>
Date: 2022-02-22 (Tue, 22 Feb 2022)
Changed paths:
M llvm/lib/Target/AArch64/AArch64InstrInfo.cpp
A llvm/test/CodeGen/AArch64/sve-fixed-ld2-alloca.ll
A llvm/test/CodeGen/AArch64/sve-ldN.mir
A llvm/test/CodeGen/AArch64/sve-stN.mir
Log Message:
-----------
[AArch64][SVE] Add structured load/store opcodes to getMemOpInfo
Currently, loading from or storing to a stack location with a structured load
or store crashes in isAArch64FrameOffsetLegal as the opcodes are not handled by
getMemOpInfo. This patch adds the opcodes for structured load/store instructions
with an immediate index to getMemOpInfo & getLoadStoreImmIdx, setting appropriate
values for the scale, width & min/max offsets.
Reviewed By: sdesmalen, david-arm
Differential Revision: https://reviews.llvm.org/D119338
(cherry picked from commit fc1b21228e39d63f1a2ab98026d548de66cb3760)
Commit: 1362f8bdfce732d99ad28556dcff4a0bcb391528
https://github.com/llvm/llvm-project/commit/1362f8bdfce732d99ad28556dcff4a0bcb391528
Author: Bradley Smith <bradley.smith at arm.com>
Date: 2022-02-22 (Tue, 22 Feb 2022)
Changed paths:
M llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
A llvm/test/CodeGen/AArch64/sve-fixed-length-fp-convert.ll
Log Message:
-----------
[AArch64][SVE] Fix selection failure caused by fp/int convert using non-Neon types
Fixes: #53679
Differential Revision: https://reviews.llvm.org/D119428
(cherry picked from commit c53ad72aa93646a3ab1b9b2307319a7389a51039)
Commit: 8c33ea3ab0ef304e6f43be31e9c72660a6261bf7
https://github.com/llvm/llvm-project/commit/8c33ea3ab0ef304e6f43be31e9c72660a6261bf7
Author: David Sherwood <david.sherwood at arm.com>
Date: 2022-02-22 (Tue, 22 Feb 2022)
Changed paths:
M llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
M llvm/test/CodeGen/AArch64/sve-extract-fixed-vector.ll
A llvm/test/CodeGen/AArch64/sve-fixed-length-reshuffle.ll
Log Message:
-----------
[SVE][CodeGen] Bail out for scalable vectors in AArch64TargetLowering::ReconstructShuffle
Previously the code in AArch64TargetLowering::ReconstructShuffle assumed
the input vectors were always fixed-width, however this is not always
the case since you can extract elements from scalable vectors and insert
into fixed-width ones. We were hitting crashes here for two different
cases:
1. When lowering a fixed-length vector extract from a scalable vector
with i1 element types. This happens due to the fact the i1 elements
get promoted to larger integer types for fixed-width vectors and leads
to sequences of INSERT_VECTOR_ELT and EXTRACT_VECTOR_ELT nodes. In this
case AArch64TargetLowering::ReconstructShuffle will still fail to make
a transformation, but at least it no longer crashes.
2. When lowering a sequence of extractelement/insertelement operations
on mixed fixed-width/scalable vectors.
For now, I've just changed AArch64TargetLowering::ReconstructShuffle to
bail out if it finds a scalable vector.
Tests for both instances described above have been added here:
(1) CodeGen/AArch64/sve-extract-fixed-vector.ll
(2) CodeGen/AArch64/sve-fixed-length-reshuffle.ll
Differential Revision: https://reviews.llvm.org/D116602
(cherry picked from commit a57a7f3de551bd0ae4e27b1f0c85437cd3e2e834)
Commit: 8b5b29c4c2c541ae23bcb51c57ce4bb57de477d1
https://github.com/llvm/llvm-project/commit/8b5b29c4c2c541ae23bcb51c57ce4bb57de477d1
Author: David Sherwood <david.sherwood at arm.com>
Date: 2022-02-22 (Tue, 22 Feb 2022)
Changed paths:
M llvm/lib/Analysis/IVDescriptors.cpp
M llvm/unittests/Analysis/IVDescriptorsTest.cpp
Log Message:
-----------
Fix incorrect TypeSize->uint64_t cast in InductionDescriptor::isInductionPHI
The code was relying upon the implicit conversion of TypeSize to
uint64_t and assuming the type in question was always fixed. However,
I discovered an issue when running the canon-freeze pass with some
IR loops that contains scalable vector types. I've changed the code
to bail out if the size is unknown at compile time, since we cannot
compute whether the step is a multiple of the type size or not.
I added a test here:
Transforms/CanonicalizeFreezeInLoops/phis.ll
Differential Revision: https://reviews.llvm.org/D118696
(cherry picked from commit 1badfbb4fc1a16f6dbe3b4edccdef44d9142857e)
Commit: 03d9a4094763b33be4e1ae908f5ff9a1787cf8d3
https://github.com/llvm/llvm-project/commit/03d9a4094763b33be4e1ae908f5ff9a1787cf8d3
Author: Bradley Smith <bradley.smith at arm.com>
Date: 2022-02-22 (Tue, 22 Feb 2022)
Changed paths:
M llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
M llvm/test/CodeGen/AArch64/sve-fixed-length-shuffles.ll
Log Message:
-----------
[AArch64][SVE] Fix selection failure during lowering of shuffle_vector
The lowering code for shuffle_vector has a code path that looks through
extract_subvector, this code path did not properly account for the
potential presense of larger than Neon vector types and could produce
unselectable DAG nodes.
Differential Revision: https://reviews.llvm.org/D119252
(cherry picked from commit 98936aee7d41f9ae60dd06558fbbb1e6a4a89e17)
Commit: 46266b3518b6190d4eaa8e4920371c87fd784f46
https://github.com/llvm/llvm-project/commit/46266b3518b6190d4eaa8e4920371c87fd784f46
Author: Rainer Orth <ro at CeBiTec.Uni-Bielefeld.DE>
Date: 2022-02-22 (Tue, 22 Feb 2022)
Changed paths:
M mlir/include/mlir/ExecutionEngine/SparseTensorUtils.h
M mlir/lib/ExecutionEngine/SparseTensorUtils.cpp
Log Message:
-----------
[mlir][sparse] Rename index_t to index_type again
While testing LLVM 14.0.0 rc1 on Solaris, I ran into a compile failure:
from /var/llvm/llvm-14.0.0-rc1/rc1/llvm-project/mlir/lib/ExecutionEngine/SparseTensorUtils.cpp:22:
/usr/include/sys/types.h:103:16: error: conflicting declaration ‘typedef short int index_t’
103 | typedef short index_t;
| ^~~~~~~
In file included from
/var/llvm/llvm-14.0.0-rc1/rc1/llvm-project/mlir/lib/ExecutionEngine/SparseTensorUtils.cpp:17:
/var/llvm/llvm-14.0.0-rc1/rc1/llvm-project/mlir/include/mlir/ExecutionEngine/SparseTensorUtils.h:26:7:
note: previous declaration as ‘using index_t = uint64_t’
26 | using index_t = uint64_t;
| ^~~~~~~
The same issue had already occured in the past and fixed in D72619
<https://reviews.llvm.org/D72619>. More detailed explanation can also be
found there.
Tested on `amd64-pc-solaris2.11` and `sparcv9-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D119323
(cherry picked from commit d2215e79ac27301c2a7cad36b5bfe20bd12837fb)
Compare: https://github.com/llvm/llvm-project/compare/08ad9ae10f32...46266b3518b6
More information about the All-commits
mailing list