The untested option triggers an IgnoredGCCCompat warning while GCC reports an error.
We support a few -X{assembler,linker,...}. Having the Joined -X may make typos unnoticed.
When a runtime is enabled through LLVM_ENABLE_RUNTIMES, it is loaded
after other projects (i.e. after LLDB). This means that the
corresponding targets don't exist when LLDB is configured. To support
runtimes being enable this way, we need to check if they're listed in
LLVM_ENABLE_RUNTIMES. For runtimes being enabled as projects (i.e.
through LLVM_ENABLE_RUNTIMES) we need to check for the target.
This patch unifies things and correctly adds compiler-rt and libcxx as
test dependencies in both scenarios.
This patch ensures that index integer attributes can only be
constructed with APInts whose widths are equal to the index
internal storage bitwidth (64).
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D133059
Some targets like RISC-V require operands to be inspected to
determine if an instruction is similar to a move.
Spotted while investigating code differences between using an ADDI
vs an ADDIW. RISC-V has the isAsCheapAsAMove flag for ADDI, but
the TII hook checks the immediate is 0 or the register is X0. ADDIW
is never generated with X0 or with an immediate of 0 so it doesn't
have the isAsCheapAsAMove flag.
I don't know enough about the PRE code to write a test for this yet.
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D132981
We used to select the runtime function based on the first argument's
type, which was not correct behavior. The selection is done using
the result type now.
Differential Revision: https://reviews.llvm.org/D133032
HasCppTypeFor<> used to evaluate to false always, so kind 10 and 16
variants of dot_product were not instantiated even though the host
supported 80- and 128-bit real and complex data types.
In addition, HAS_FLOAT128 was not enabling complex kind=16 variant
of dot_product. This is fixed now.
Note that the change for HasCppTypeFor<> may also affect other
functions such as matmul, i.e. kind 10 and 16 variants of them
may become available now (depending on the build host).
Differential Revision: https://reviews.llvm.org/D133051
Introduce new sparse_tensor.storage_get/set to access memory that stores the handle of a sparse tensor. The sparse tensor storage are represented as a tuple, these operation will later be eliminated and the tuple will be flattened after sparse tensor codegen
Reviewed By: aartbik
Differential Revision: https://reviews.llvm.org/D133049
This builds a compound type for the buffers required for the sparse storage scheme defined by the MLIR sparse tensor types. The use of a tuple allows for a simple 1:1 type conversion. A subsequent pass can expand this tuple into its component with an isolated 1:N type conversion.
Reviewed By: Peiming
Differential Revision: https://reviews.llvm.org/D133050
Missing long specifier so that a shift would occur in 64-bits rather
than implicitly in 32-bits.
Reviewed By: NatashaKnk
Differential Revision: https://reviews.llvm.org/D133058
Restore the generation of the old pass base classes for better transitioning of external projects relying on them. They were eliminated with 67d0d7ac0a.
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D133027
The ELF backend originally used `getSymbols()` but went though a
sequence of changes that resulted in this method being called
`symbols()`.
d8f8abbd4a replaced `getSymbols()` with
`forEachSymbol`.
a2fc964417 replaced `forEachSymbol` with
`llvm::iterator_range`.
e9262edf0d replaced `llvm::iterator_range`
with `symbols()`.
Differential Revision: https://reviews.llvm.org/D131284
Warn if `.size` is specified for a function symbol. The size of a
function symbol is determined solely by its content.
I noticed this simplification was possible while debugging #57427, but
this change doesn't fix that specific issue.
Differential Revision: https://reviews.llvm.org/D132929
Make the rumtimes target a test dependency. This is needed or the parts
of the test suite that rely on the libcxx and libcxxabi.
Differential revision: https://reviews.llvm.org/D133046
The amdgpu.mfma operator is a wrapper around the Matrix Fused Multiply
Add (MFMA) instructions on some AMD GPUs (the CDNA-based MI-* cards).
This interface allows for selecting the operation to be performed by
specifying the dimensions of the multiplication to be performed and
any additional attributes (such as whether to use reduced-precision
floating-point math) that are needed to select the relevant mfma
instruction and set its parameters.
Reviewed By: ThomasRaoux, nirvedhmeshram
Differential Revision: https://reviews.llvm.org/D132956
Since D129288, callbr is allowed to have duplicate successors. This patch removes a limitation which prevents optimizations from actually producing such callbrs.
This is probably the riskiest of all the recent callbr changes, because code with incorrect assumptions might be lurking somewhere. I fixed the one case I encountered ahead of time in 8201e3ef5c.
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D129997
Originally landed as
commit 08860f525a ("[Local] Allow creating callbr with duplicate successors")
Reverted in
commit 1cf6b93df1 ("Revert "[Local] Allow creating callbr with duplicate successors"")
https://reviews.llvm.org/rG6bbf51f3ed59ae37f0fec729f25af002111c9e74 from May removed Preprocessor::getPredefines() from Clang's API, presumably as a cleanup because this method is unused in the LLVM codebase.
However, it was/is used by a small number of third-party tools and is pretty harmless, so this patch adds it back and documents why it's here.
The issue was raised in https://github.com/llvm/llvm-project/issues/57483, it would be nice to be able to land it into Clang 15 as it breaks those third-party tools and we can't easily add it back in bug fix releases.
Reviewed By: brad.king, thieta
Differential Revision: https://reviews.llvm.org/D133044
We do keep using the flag with Clang, which should keep catching
such issues in buildbots.
With GCC, the warning can cause lots of loud notes about the
warning logic getting disabled in large source files.
Differential Revision: https://reviews.llvm.org/D132914
This is NOT nfc. Specifically, the following behavior changes:
* Pointers are now allowed. Both uniform, and constants.
* FP uniform non-constants can now be recognized.
* FP undefs are no longer considered constant. This matches int behavior which we had tests for. FP behavior was untested. Its not clear to me int behavior is reasonable, but it's what tests seem to expect, so go with minimum impact for now.
Seeing the wrong instruction for this name in IR is confusing.
Most of the tests are not even checking a subsequent use of
the value, so I just deleted the over-specified CHECKs.
Write a semantics test for the atomic intrinsic subroutine,
atomic_fetch_or.
Reviewed By: rouson
Differential Revision: https://reviews.llvm.org/D132519
X86 and ARM AsmParsers have this same assertion. This assertion provides better reporting when the RISCVTargetStreamer is null and helps to prevent null pointer access.
Reviewed By: bkramer
Differential Revision: https://reviews.llvm.org/D132863
VP_STORE has a Chain for operand 0, so the LEGALPOS should be 1.
VP_STORE is always considered Legal for MVT::Other. So I suspect this
was causing vp_store to be ignored by LegalizeVectorOps and instead
handled in LegalizeDAG.
VP_LOAD is Custom expanded in LegalizeVectorOps for RISC-V.
Differential Revision: https://reviews.llvm.org/D132972
The implementation currently supports only non-thumb mode. As a test for
the implementation, mmap and munmap functions have been enabled.
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D132825
This defines a new policy for removal of transitive includes.
The goal of the policy it to make it relatively easy to remove
headers when needed, but avoid breaking developers using and
vendors shipping libc++.
The method used is to guard transitive includes based on the
C++ language version. For the upcoming C++23 we can remove
headers when we want, but for other language versions we try
to keep it to a minimum.
In this code the transitive include of `<chrono>` is removed
since D128577 introduces a header cycle between `<format>`
and `<chrono>`. This cycle is indirectly required by the
Standard. Our cycle dependency tool basically is a grep based
tool, so it needs some hints to ignore cycles. With the input
of our transitive include tests we can create a better tool.
However that's out of the scope of this patch.
Note the flag `_LIBCPP_REMOVE_TRANSITIVE_INCLUDES` remains
unchanged. So users can still opt-out of transitives includes
entirely.
Reviewed By: #libc, ldionne, philnik
Differential Revision: https://reviews.llvm.org/D132284
The libc.src.__support.FPUtil.fputil target encompassed many unrelated
files, and provided a lot of hidden dependencies. This patch splits out
all of these files into component parts and cleans up the cmake files
that used them. It does not touch any source files for simplicity, but
there may be changes made to them in future patches.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D132980
Printing support enables the production of more useful error messages in unit testing e.g. when using matchers such as `UnorderedElementsAre()` to inspect the contents of a `StringMap`.
Reviewed By: gribozavr2, sgatev, ymandel
Differential Revision: https://reviews.llvm.org/D132747
Vitaly Buka