The vectoriser sometimes generates predicated vector loops using
the llvm.get.active.lane.mask intrinsic so it's important that we
are able to calculate a valid cost for the call instruction. When
SVE is enabled we are able to use a single whilelo instruction
for some vector types - in such cases I've marked the cost as 1.
For all other cases I've set the cost according to how the intrinsic
will be expanded.
Tests added here:
Analysis/CostModel/AArch64/sve-intrinsics.ll
Analysis/CostModel/ARM/active_lane_mask.ll
Analysis/CostModel/RISCV/active_lane_mask.ll
Differential Revision: https://reviews.llvm.org/D121109
Kazushi Marukawa (kaz7) of NEC Solution Innovators will take over my
role as a code owner for the Vector Engine target. Erich Focht (efocht)
of NEC will assume the administrator role for the clang-ve-ninja
buildbot.
Reviewed By: kaz7
Differential Revision: https://reviews.llvm.org/D121453
Introduce an explicit `replaceOp` call to enable the tracking of the producer LinalgOp.
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D121369
This support "DEPENDS" and "EXTRA_INCLUDES", allowing in particular
to inject include paths to a tablegen targets without forcing to go
through the global INCLUDE_DIRECTORIES property.
Differential Revision: https://reviews.llvm.org/D121568
When using COMPILER_RT_USE_BUILTINS_LIBRARY=ON and clang-cl there
where several places where it didn't work as expected.
First -print-libgcc-file-name has to be prefixed with /clang:
Then the regex that matched the builtins library was wrong because
the builtins library is called clang_rt.builtins_<arch>.lib
and the regex only matched libclang_rt.builtins_arch.a
With this commit you can use a runtime build on Windows with this
option enabled.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D120698
This allows you to set a custom path to the ThinLTO cache so that
it can be shared when building in several different build directories.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D121215
Previously the comments for configuration structs as a whole like
`BraceWrappingFlags` did not go into the doc.
Reviewed By: curdeius
Differential Revision: https://reviews.llvm.org/D120361
For when we want to change a configuration option from an enum into a
struct. The need arose when working on D119599.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D120363
This is present since the beginning, but does not seem needed by any
in-tree target right now. This seems like the kind of thing to populate
by the caller if needed.
Differential Revision: https://reviews.llvm.org/D121565
If an instruction is first legal instruction in the module, and is the only legal instruction in its basic block, it will be ignored by the outliner due to a length check inherited from the older version of the outliner that was restricted to outlining within a single basic block. This removes that check, and updates any tests that broke because of it.
Reviewer: paquette
Differential Revision: https://reviews.llvm.org/D120786
As noticed in D119654, by adding the masked intrinsics results together
we can end up with the selects being canonicalized away from the
intrinsic - this isn't what we want to test here so replace with a
insertvalue chain into a aggregate instead to retain all the results.
Differential Revision: https://reviews.llvm.org/D121563
Musttail calls require extra handling to properly propagate the calling convention information and tail call information. The outliner does not currently do this, so we ignore call instructions that utilize the swifttailcc and tailcc calling convention as well as functions marked with the attribute musttail.
Reviewers: paquette, aschwaighofer
Differential Revision: https://reviews.llvm.org/D120733
As noticed in D119654, by adding the masked intrinsics results together we can end up with the selects being canonicalized away from the intrinsic - this isn't what we want to test here so replace with a insertvalue chain into a aggregate instead to retain all the results.
As noticed in D119654, by adding the masked intrinsics results together we can end up with the selects being canonicalized away from the intrinsic - this isn't what we want to test here so replace with a insertvalue chain into a aggregate instead to retain all the results.
This patch is a follow-up to D115953. It updates optimizeInductions
to also introduce new VPScalarIVStepsRecipes if an IV has both vector
and scalar uses.
It updates all uses that only need scalar values to use the newly
created recipe for the scalar steps.
This completes untangling of VPWidenIntOrFpInductionRecipe
code-generation. Now the recipe *only* creates the widened vector
values, as it says on the tin.
The code to genereate IR has been moved directly to
VPWidenIntOrFpInductionRecipe::execute.
Note that the recipe has been updated to hold a reference to
ScalarEvolution, which is needed to expand the step, until we can place
the corresponding SCEV expansion in the pre-header.
Depends on D120827.
Reviewed By: Ayal
Differential Revision: https://reviews.llvm.org/D120828
It was probably a copy-paste mistake.
The check was added as `cert-dcl58-cpp`, so the doc should point there.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D121373
The docs URL was dangling, and the docs suggested that it has no fixits,
but it actually had.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D121372
Document the connection between this checker and the corresponding CERT
rule.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D121214
All supported compilers that support C++20 now support concepts. So, remove
`_LIB_LIBCPP_HAS_NO_CONCEPTS` in favor of `_LIBCPP_STD_VER > 17`. Similarly in
the tests, remove `// UNSUPPORTED: libcpp-no-concepts`.
Differential Revision: https://reviews.llvm.org/D121528
We do not have general reassociation here (and probably
do not need it), but I noticed these were missing in
patches/tests motivated by D111530, so we can at
least handle the simplest patterns.
The VE test diff looks correct, but we miss that
pattern in IR currently:
https://alive2.llvm.org/ce/z/u66_PM
This patch adds supports for union of relations (PresburgerRelation). Along
with this, support for PresburgerSet is also maintained.
This patch is part of a series of patches to add support for relations in
Presburger library.
Reviewed By: arjunp
Differential Revision: https://reviews.llvm.org/D121417
If we're comparing a value against zero, strip away any zero-extension and perform the comparison on the pre-extended value
Fixes#38308
Differential Revision: https://reviews.llvm.org/D121472
Current generated Python binding for the SCF dialect does not allow
users to call IfOp to create if-else branches on their own.
This PR sets up the default binding generation for scf.if operation
to address this problem.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D121076
If the type is less than XLenVT, type legalization will turn this
into (srl (bitreverse (bswap (srl (bswap X), C))), C). We can't
completely recover from these shifts. They introduce zeros into
the upper bits of the result and we can't easily tell if they are
needed. By doing a DAG combine early, we avoid introducing these
shifts.
Where possible, I added additional information to the messages to help
programmers figure out what went wrong. I also removed all uses of the word
"bad" from the messages since (to me) that implies a moral judgement rather
than a programming error. I replaced it with either "invalid" or "unsupported"
where appropriate.
Differential Revision: https://reviews.llvm.org/D121493
David Sherwood