This can be a pre-processing for bufferization and allows for more efficient lowerings without an alloc.
Differential Revision: https://reviews.llvm.org/D142207
This can be a pre-processing for bufferization and allows for more efficient lowerings without an alloc.
Differential Revision: https://reviews.llvm.org/D142205
Righteously there shouldn't be any special cases here because
`HasTailPolicy` and `HasMaskPolicy` is able to express necessary cases.
This commit is a part of the step-by-step effort to remove
`Policy::Scheme::Omit`, which completely does not make sense in RVV 1.0
because an RVV instruction always executes with `vta` and `vma` set
to a certain value.
This is the 5th commit of a patch-set that aims to change the default policy
for RVV intrinsics from TAMU to TAMA.
Please refer to the cover letter in the 1st commit (D141573) for an
overview.
Reviewed By: craig.topper, kito-cheng
Differential Revision: https://reviews.llvm.org/D141754
`PolicyAttrs::IsUnspecified` is modified in
`RVV::Intrinsic::computeBuiltInTypes` and used under
`RVVIntrinsic::updateNamesAndPolicy`. Suprisingly the modification
in `RVV::Intrinsic::computeBuiltInTypes` is completely unnecessary.
This commit removes the redundant logic.
This is the 4th commit of a patch-set that aims to change the default policy
for RVV intrinsics from TAMU to TAMA.
Please refer to the cover letter in the 1st commit (D141573) for an
overview.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D141577
This is the 3rd commit of a patch-set that aims to change the default policy
for RVV intrinsics from TAMU to TAMA.
Please refer to the cover letter in the 1st commit (D141573) for an
overview.
Reviewed By: kito-cheng
Differential Revision: https://reviews.llvm.org/D141575
The original naming is inaccurate. An RVV intrinsic always comes with
a corresponding policy behavior. When the policy is unspecified for an
intrinsic, its policy behavior should be it's default assumption.
This is the 2nd commit of a patch-set that aims to change the default policy
for RVV intrinsics from TAMU to TAMA.
Please refer to the cover letter in the 1st commit (D141573) for an
overview.
Reviewed By: kito-cheng
Differential Revision: https://reviews.llvm.org/D141574
This is the 1st commit of a patch-set that aims to change the default policy
for RVV intrinsics from TAMU to TAMA.
The patch-set work towards the simplification proposal [0] of Nick
Knight. After this patch-set, all intrinsics operates under a general
assumption that the policy behavior is agnostic.
You may find that most of the patches are NFC patches. They subtly remove
implicit assumptions that entangles the codebase, making the singular patch
that contains functional change clear and obvious.
In [2/15], The attribute `Policy::IsPolicyNone` may give the mis-perception
that an RVV intrinsic may operate without any policy. However this is not the
case because the policy CSR-s (`vta` and `vma`) always affect an RVV
instruction's behavior, except that some instructions have policy always set
as agnostic (e.g. instructions with a mask destination register is always
tail agnostic).
Next, to perform the change from TAMU to TAMA, we need to first remove
`Policy::PolicyType::Omit`. [4/15] ~ [12/15] removes it with NFC patches step
by step. Without the patches, directly applying [14/15] to the existing codebase
will not work because there will be complicated logics that are scattered in
places that is hard to maintain.
[1/15], [3/15] are not related to the main goal of this patch-set, they were
clean-up along the way as I was going through the codebase. [13/15] is a
clean-up that was an oversight in D141198.
Finally, [14/15] performs the functional change this patch-set aims for. The
default policy is changed from TAMU to TAMA. This affects the masked version of
the intrinsics without a policy suffix. The masked-off operand is removed. Due
to the removal, masked version of `vid` and `viota` intrinsics are no longer
available for overloading.
[15/15] is a final commit to set data members of `Policy` as constants. Through
the refactoring the class `Policy` is now correct-by-construction.
The next patch-set will be to remove redundant intrinsics with a policy suffix
`_ta` and `_tama` intrinsics are redundant and will be removed. Other policy
suffix will be renamed to adapt to the general assumption that policy is
generally agnostic.
[0] https://gist.github.com/nick-knight/6cb0b74b351a25323dfb1821d3a269b9
Pull Request: riscv-non-isa/rvv-intrinsic-doc#186
Reviewed By: craig.topper, kito-cheng
Differential Revision: https://reviews.llvm.org/D141573
This is the 7th commit of a patch-set that aims to remove the
IsPrototypeDefaultTU special case for the rvv-intrinsics.
This is the final commit of the patch-set. Now that no intrinsics is
using the attribute, we are safe to remove it.
Please refer to the cover letter in the 1st commit (D140895) for an
overview.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D140954
The destination parameter is removed for non-policy unmasked intrinsics.
The default policy for non-policy (implicit) vmv_s_x and vfmv_s_f
intrinsics will be tail agnostic and mask undisturbed.
Upon change of prototype, vmv_s_x and vfmv_s_f is no longer able to
have an overloading version for its non-policy and tail agnostic
intrinsics.
This is the 6th commit of a patch-set that aims to remove the
IsPrototypeDefaultTU special case for the rvv-intrinsics.
Please refer to the cover letter in the 1st commit (D140895) for an
overview.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D140947
The destination parameter is removed for non-policy unmasked intrinsics.
The default policy for non-policy (implicit) vcompress intrinsics will
be tail agnostic and mask undisturbed.
This is the 5th commit of a patch-set that aims to remove the
IsPrototypeDefaultTU special case for the rvv-intrinsics.
Please refer to the cover letter in the 1st commit (D140895) for an
overview.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D140942
The destination parameter is still needed as the computation requires
so.
The default policy for non-policy (implicit) vslideup intrinsics
will be tail agnostic and mask undisturbed.
This is the 4th commit of a patch-set that aims to remove the
IsPrototypeDefaultTU special case for the rvv-intrinsics.
Please refer to the cover letter in the 1st commit (D140895) for an overview.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D140941
The destination parameter is removed for non-policy unmasked vslidedown
intrinsics.
The default policy for non-policy (implicit) vslidedown intrinsics will
be tail agnostic and mask undisturbed.
This is the 3rd commit of a patch-set that aims to remove the
IsPrototypeDefaultTU special case for the rvv-intrinsics.
Please refer to the cover letter in the 1st commit (D140895) for an
overview.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D140937
The destination parameter is still needed as elements of
0 < i < max(vstart, OFFSET) in vd remains unchanged.
The default policy for non-policy (implicit) vslideup intrinsics
will be tail agnostic and mask undisturbed.
This is the 2nd commit of a patch-set that aims to remove the
IsPrototypeDefaultTU special case for the rvv-intrinsics.
Please refer to the cover letter in the 1st commit (D140895) for an overview.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D140936
The destination parameter is removed for non-policy unmasked intrinsics,
they are now tail agnostic. The non-policy masked intrinsics are tail
agnostic and masked undisturbed, just like normal instructions like
vadd.
This is the 1st commit of a patch-set that aims to remove the
`IsPrototypeDefaultTU` special case for the rvv-intrinsics.
The patch-set work towards the simplification proposal [0] of Nick
Knight, the plan is that after this patch-set, all non-policy
intrinsics will be aligned with default policy behavior of tail
agnostic and mask undisturbed. Then the next patch-set will aim
towards changing non-policy intrinsics to tail agnostic and mask
agnostic.
[0] https://gist.github.com/nick-knight/6cb0b74b351a25323dfb1821d3a269b9
Pull Request: riscv-non-isa/rvv-intrinsic-doc#186
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D140895
At each call to findFirstSet in this patch, the argument is known to
be nonzero, so we can safely switch to llvm::countr_zero, which will
become std::countr_zero once C++20 is available.
If an instruction is executed in an aligned region we can ignore
threading effects and use CFG reasoning (dominance and reachability).
This is true because all threads are together in an aligned region and
there cannot be one waiting for a signal at a place not connected via
the control flow.
More dedicated tests will follow.
More details can be found here:
"Co-Designing an OpenMP GPU Runtime and Optimizations for Near-Zero
Overhead Execution", IPDPS 2022,
https://www.osti.gov/servlets/purl/1890094
If the current calling convection CurCC is not equal to Target calling
convection ToCC and current calling convention (CurCC) is equal to the
default calling convention (DefaultCC), that means DefaultCC can not be
equal to ToCC so the right part of the expression DefaultCC == ToCC is
not needed.
revelant code -
if (CurCC == ToCC)
return;
if (CurCC != DefaultCC || DefaultCC == ToCC)
return;
Found by PVS-Studio - https://pvs-studio.com/en/blog/posts/cpp/1003/, N41.
Differential Revision: https://reviews.llvm.org/D142338
There is already a GCC compatibility gap on AIX, & GCC compatibility is
not a concern on z/OS. GCC compatibility is not sufficient motivation
for breaking ABI on AIX and z/OS. This opts out of changes introduced in
https://reviews.llvm.org/D119051. For AIX only, also opt out of D117616
(which z/OS had picked up at the time ABI stabilization occurred).
Differential Revision: https://reviews.llvm.org/D142358
This patch does two things, both related to support of multi-exit loops with
many exits that have known symbolic max exit count. They can theoretically
go independently, but I don't know how to write a test showing separate
impact.
Part 1: `SkipLastIter` can be set to `true` not when a particular exit has exit
count same as the whole loop (and therefore it must exit on the last iteration),
but when the aggregate of first few exits has umin same as whole loop exit count.
It means that it's not known which of them will exit exactly, but one of them will.
Part 2: when `SkipLastIter` is set, and exit count is `umin(a, b, c)`, instead of
`umin(a, b, c) - 1` use `umin(a - 1, b - 1, c - 1)`. We don't care about overflows
here, but the further logic knows how to deal with umin by element, but the
`SCEVAddExpr` node will confuse it.
Differential Revision: https://reviews.llvm.org/D141361
Reviewed By: nikic
When exit by condition `C1` dominates exit by condition `C2`, and
max symbolic exit count for `C1` matches those for loop, we will
apply more optimistic logic to `C2` by setting `SkipLastIter` for it,
meaning that it will do 1 iteration less because the dominating branch
must exit on the last loop iteration.
But when we have a single exit by condition `C1 & C2`, we cannot
apply the same logic, because there is no dominating condition.
However, if we can prove that the symbolic max exit count of `C1 & C2`
matches those of `C1`, it means that for `C2` we can assume that it
doesn't matter on the last iteration (because the whole thing is `false`
because `C1` must be `false`). Therefore, in this situation, we can handle
`C2` as if it had `SkipLastIter`.
Differential Revision: https://reviews.llvm.org/D139934
Reviewed By: nikic
This commit adds location attributes and arrays of locations to OpBase.td.
Using LocationAttrs directly in an operation is useful when the location does
not correspond 1-1 to an operation or value in the IR. We use this in CIRCT to
store the declaration location of result ports of HWModule operations.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D142148
If we modified the IR during manifest, e.g., SPMDzation, we might end up
with un-cached reachability queries. This is not good as the result is
going to be optimistic. We now cache the updateImpl result and use it
during manifest.
Bug was exposed in a follow up extension.
There is a typo in the cmake configuration. It should be
RISCVTargetParserTableGen, not RISCVTargetParserTablegen.
This reverts commit 5d02e38f56dfa6c46dd71658c185582af1ffb07b.
LLVM currently uses LDAR/STLR and variants for acquire/release
as well as seq_cst operations. This is fine as long as all code uses
this convention.
Normally LDAR/STLR act as one way barriers but when used in
combination they provide a sequentially consistent model. i.e.
when an LDAR appears after an STLR in program order the STLR
acts as a two way fence and the store will be observed before
the load.
The problem is that normal loads (unlike ldar), when they appear
after the STLR can be observed before STLR (if my understanding
is correct). Possibly providing weaker than expected guarantees if
they are used for ordered atomic operations.
Unfortunately in Microsoft Visual Studio STL seq_cst ld/st are
implemented using normal load/stores and explicit fences:
dmb ish + str + dmb ish
ldr + dmb ish
This patch uses fences for MSVC target whenever we write to the
memory in a sequentially consistent way so that we don't rely on
the assumptions that just using LDAR/STLR will give us sequentially
consistent ordering.
Differential Revision: https://reviews.llvm.org/D141748
Change-Id: I48f3500ff8ec89677c9f089ce58181bd139bc68a
This copies the atomic-ops file.
Committed without review.
Differential Revision: https://reviews.llvm.org/D141964
Change-Id: I7d7b05339d9ca23f88848c56f73a3e4d3e1abeba
Summary:
I removed some documentation but not its Sphinx index, this fixes that.
Also I realized that we had a tool in the header still around so that's
gone too.
In practice the change from an unspecified underlying type to uint8_t in
25c0ea2a5370813f46686918a84e0de27e107d08 means some builds break due to
ambiguity resolving operator<< on ostreams (I assume because they define
uint8_t differently).
There were also valid points raised on the review saying that we can
just use int here anyway. Pinning it to any type removes the potential
for UB when constructing it, and int is the de-facto default.
