Some LLVM unit tests forget to clean up temporary files and
directories. Introduce RAII classes for cleaning them up.
Refactor the tests to use those classes.
Differential Revision: https://reviews.llvm.org/D83228
The wording before this patch applies to llvm.mem.parallel_loop_access, not access groups.
Reviewed By: mppf, hfinkel
Differential Revision: https://reviews.llvm.org/D83781
This patch adds an initial, incomeplete and unsound implementation of
canReplacePointersIfEqual to check if a pointer value A can be replaced
by another pointer value B, that are deemed to be equivalent through
some means (e.g. information from conditions).
Note that is in general not sound to blindly replace pointers based on
equality, for example if they are based on different underlying objects.
LLVM's memory model is not completely settled as of now; see
https://bugs.llvm.org/show_bug.cgi?id=34548 for a more detailed
discussion.
The initial version of canReplacePointersIfEqual only rejects a very
specific case: replacing a pointer with a constant expression that is
not dereferenceable. Such a replacement is problematic and can be
restricted relatively easily without impacting most code. Using it to
limit replacements in GVN/SCCP/CVP only results in small differences in
7 programs out of MultiSource/SPEC2000/SPEC2006 on X86 with -O3 -flto.
This patch is supposed to be an initial step to improve the current
situation and the helper should be made stricter in the future. But this
will require careful analysis of the impact on performance.
Reviewed By: aqjune
Differential Revision: https://reviews.llvm.org/D85524
Interleave for small loops that have reductions inside,
which breaks dependencies and expose.
This gives very significant performance improvements for some benchmarks.
Because small loops could be in very hot functions in real applications.
Differential Revision: https://reviews.llvm.org/D81416
Previously if the source match we asserted that the destination
matched. But GPR <-> mask register copies on X86 can violate this
since we use the same K-registers for multiple sizes.
Fixes this ISPC issue https://github.com/ispc/ispc/issues/1851
Differential Revision: https://reviews.llvm.org/D86507
This reverts commit bc9a29b9ee6ade4894252b1470977142c32b4602.
The reasoning that this patch was wrong was itself incorrect
(see discussion on llvm-commits). This patch does seem to be exposing
a latent SVE code generation bug on non-public tests, which should
not block a correctness fix for public, non-SVE use cases.
General purpose registers 30 and 31 are handled differently when they are
reserved as the base-pointer and frame-pointer respectively. This fixes the
offset of their fixed-stack objects when there are fpr calle-saved registers.
Differential Revision: https://reviews.llvm.org/D85850
I was recently debugging a similar issue to https://reviews.llvm.org/D86500 only with a large metadata section. Only after I finished debugging it did I discover it was fixed very recently.
My version of the fix was going to alignTo since that uses uint64_t and improves the readability of the code. So I though I would go ahead and share it.
Differential Revision: https://reviews.llvm.org/D86957
This is needed for an upcoming change to how we translate conditional branches
which might generate these.
Differential Revision: https://reviews.llvm.org/D86383
These instructions actually use a 512-byte location, where bytes 464-511 are ignored.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D86942
On -O0, i1 strict_fsetcc will be promoted to i32. We don't handle that
in TD patterns. This patch fills logic in PPCISelDAGToDAG to handle more
cases.
Reviewed By: uweigand
Differential Revision: https://reviews.llvm.org/D86595
This patch adds the td instruction definitions of the xvcvspbf16 and xvcvbf16spn
instructions, along with their respective MC tests.
Differential Revision: https://reviews.llvm.org/D86794
This reverts commit e9d9a612084b47fc4277523561d61e675370c854.
This patch was previously revert by 04879086b44348cad600a0a1ccbe1f7776cc3cf9
with the reapplication being done after breaking the assert used to
ensure SP is always 16-byte aligned, which is a requirement of the AAPCS.
For extra context the latest patch caused runtime failures when
building with "-march=armv8-a+sve -mllvm -aarch64-sve-vector-bits-min=256".
Unmerges have the same fundamental problem as G_TRUNC, and G_TRUNC
could be implemented in terms of G_UNMERGE_VALUES. Reducing the number
of elements in unmerge results ends up producing the original unmerge
type profile, so the artifact combiner needs to eliminate the
intermediate illegal registers. This avoids infinite looping in the
legalizer in a future change.
Assuming an unmerge has each result unmerged the same way, this ends
up producing a new unmerge of the source for every definition. I'm not
sure if the artifact combiner should either insert temporary merges
here and erase the original merge, or if the combiner should look at
uses from defs rather than defs from uses for unmerges.
In a few cases this regresses from using 16-bit shifts for 8-bit
values to using 32-bit shifts, but I think these can be legalized
later (the other legalization rules don't try very hard to use 16-bit
shifts either).
Currently the dbg_value ends up in the relaxed branch block. A future
commit will push the dbg_value out of this block, and I'm not sure how
to coax the IR into producing the same MIR at the relevant point.
Loop Idiom Recognize Pass (LIRP) attempts to transform loops with subscripted arrays
into memcpy/memset function calls. In some particular situation, this transformation
introduces negative impacts. For example: https://bugs.llvm.org/show_bug.cgi?id=47300
This patch will enable users to disable a particular part of the transformation, while
he/she can still enjoy the benefit brought about by the rest of LIRP. The default
behavior stays unchanged: no part of LIRP is disabled by default.
Reviewed By: etiotto (Ettore Tiotto)
Differential Revision: https://reviews.llvm.org/D86262
We have Error.cpp/.h which contains some code for working with error codes.
In fact we use Error/Expected<> almost everywhere already and we can get rid
of these files.
Note: a few places in the code used readobj specific error codes,
e.g. `return readobj_error::unknown_symbol`. But these codes are never really used,
i.e. the code checks the fact of a success/error call only.
So I've changes them to `return inconvertibleErrorCode()` for now.
It seems that these places probably should be converted to use `Error`/`Expected<>`.
Differential revision: https://reviews.llvm.org/D86772
This relands e9a3d1a401b07cbf7b11695637f1b549782a26cd which was originally
missing linking LLVMSupport into LLMVFileCheck which broke the SHARED_LIBS build.
Original summary:
The actual FileCheck logic seems to be implemented in LLVMSupport. I don't see a
good reason for having FileCheck implemented there as it has a very specific use
while LLVMSupport is a dependency of pretty much every LLVM tool there is. In
fact, the only use of FileCheck I could find (outside the FileCheck tool and the
FileCheck unit test) is a single call in GISelMITest.h.
This moves the FileCheck logic to its own LLVMFileCheck library. This way only
FileCheck and the GlobalISelTests now have a dependency on this code.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D86344
This patch adds tests for dumping the .debug_line_str section. The
dumper of the debug_line_str section is able to write nonprintable
strings as escaped chars while the dumper of the debug_str and
debug_str.dwo sections cannot. I will fix them and add tests for them
in a follow-up patch.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D86916
`amdgpu-elf-definitions.test` is a file that tests
`Format`, 'OS/ABI' and 'Machine' fields printed for EM_AMDGPU.
It uses a precompiled object.
It is not needed to have it, because:
1) We already test formats in `file-header-format.test` + `llvm/unittests/Object/ELFObjectFileTest.cpp`.
2) We test 'OS/ABI' in `file-header-os-abi.test` for all possible values.
3) We test machine types in `file-header-machine-types.test`
In addition we have `amdgpu-elf-headers.test` which tests EM_AMDGPU specific flags. I.e.
it also tests the fact that llvm-readobj/elf are able to dump such objects.
This patch removes the test case and the corresponding binary.
Differential revision: https://reviews.llvm.org/D86774
This replaces `reportError` calls with `reportUniqueWarning` and improves testing
for the code that is related to stack sizes dumping.
Differential revision: https://reviews.llvm.org/D86783
I have fixed up a number of warnings resulting from TypeSize -> uint64_t
casts and calling getVectorNumElements() on scalable vector types. I
think most of the changes are fairly trivial except for those in
DAGTypeLegalizer::SplitVecRes_MLOAD I've tried to ensure we create
the MachineMemoryOperands in a sensible way for scalable vectors.
I have added a CHECK line to the following test:
CodeGen/AArch64/sve-split-load.ll
that ensures no new warnings are added.
Differential Revision: https://reviews.llvm.org/D86697
