This adds IGLP mutation to the iterative schedulers
(`gcn-iterative-max-occupancy-experimental`, `gcn-iterative-minreg`, and
`gcn-iterative-ilp`).
The `gcn-iterative-minreg` and `gcn-iterative-ilp` schedulers never
actually applied the mutations added, so this also has the effect of
teaching them about mutations in general. The
`gcn-iterative-max-occupancy-experimental` scheduler has calls to
`ScheduleDAGMILive::schedule()`, so, before this, mutations were applied
at this point. Now this is done during calls to `BuildDAG`, with IGLP
superseding other mutations (similar to the other schedulers). We may
end up scheduling regions multiple times, with mutations being applied
each time, so we need to track for
`AMDGPU::SchedulingPhase::PreRAReentry`
Fixes what seems to be a buggy warning in MSVC:
```
[1/37] Building CXX object tools\clang\lib\Sema\CMakeFiles\obj.clangSema.dir\SemaConcept.cpp.obj
C:\git\llvm-project\clang\lib\Sema\SemaConcept.cpp(1933): warning C4101: '$S26': unreferenced local variable
```
Fixes:
```
[6373/7138] Building CXX object tools\lldb\tools\lldb-dap\CMakeFiles\lldb-dap.dir\DAP.cpp.obj
C:\git\llvm-project\lldb\tools\lldb-dap\DAP.cpp(725) : warning C4715: '`lldb_dap::DAP::HandleObject'::`30'::<lambda_2>::operator()': not all control paths return a value
[6421/7138] Building CXX object tools\lldb\tools\lldb-dap\CMakeFiles\lldb-dap.dir\Protocol\ProtocolTypes.cpp.obj
C:\git\llvm-project\lldb\tools\lldb-dap\Protocol\ProtocolTypes.cpp(203) : warning C4715: 'lldb_dap::protocol::ToString': not all control paths return a value
C:\git\llvm-project\lldb\tools\lldb-dap\Protocol\ProtocolTypes.cpp(98) : warning C4715: 'lldb_dap::protocol::toJSON': not all control paths return a value
C:\git\llvm-project\lldb\tools\lldb-dap\Protocol\ProtocolTypes.cpp(72) : warning C4715: 'lldb_dap::protocol::toJSON': not all control paths return a value
C:\git\llvm-project\lldb\tools\lldb-dap\Protocol\ProtocolTypes.cpp(111) : warning C4715: 'lldb_dap::protocol::toJSON': not all control paths return a value
[6426/7138] Building CXX object tools\lldb\tools\lldb-dap\CMakeFiles\lldb-dap.dir\Protocol\ProtocolBase.cpp.obj
C:\git\llvm-project\lldb\tools\lldb-dap\Protocol\ProtocolBase.cpp(287) : warning C4715: 'lldb_dap::protocol::fromJSON': not all control paths return a value
```
Found when building with MSVC on Windows, was seeing:
```
[2703/7138] Building CXX object tools\lldb\source\Plugins\Process\Utility\CMakeFiles\lldbPluginProcessUtility.dir\NativeRegisterContextDBReg.cpp.obj
C:\git\llvm-project\lldb\source\Plugins\Process\Utility\NativeRegisterContextDBReg.cpp(286): warning C4305: 'return': truncation from 'unsigned int' to 'bool'
```
Fixes:
```
[6113/7139] Building CXX object projects\compiler-rt\lib\interception\CMakeFiles\RTInterception.x86_64.dir\interception_win.cpp.obj
C:\git\llvm-project\compiler-rt\lib\interception\interception_win.cpp(746,5): warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
746 | case 0xB841: // 41 B8 XX XX XX XX : mov r8d, XX XX XX XX
| ^
C:\git\llvm-project\compiler-rt\lib\interception\interception_win.cpp(746,5): note: insert 'FALLTHROUGH;' to silence this warning
746 | case 0xB841: // 41 B8 XX XX XX XX : mov r8d, XX XX XX XX
| ^
| FALLTHROUGH;
C:\git\llvm-project\compiler-rt\lib\interception\interception_win.cpp(746,5): note: insert 'break;' to avoid fall-through
746 | case 0xB841: // 41 B8 XX XX XX XX : mov r8d, XX XX XX XX
| ^
| break;
1 warning generated.
```
Fixes:
```
[113/324] Building CXX object tools\clang\unittests\AST\ByteCode\CMakeFiles\InterpTests.dir\BitcastBuffer.cpp.obj
C:\git\llvm-project\clang\unittests\AST\ByteCode\BitcastBuffer.cpp(52): warning C4309: 'initializing': truncation of constant value
C:\git\llvm-project\clang\unittests\AST\ByteCode\BitcastBuffer.cpp(53): warning C4309: 'initializing': truncation of constant value
```
This PR upstreams the `SMT` dialect from the CIRCT project. Here we only
check in the dialect/op/types/attributes and lit tests. Follow up PRs
will add conversions in and out and etc.
Co-authored-by: Bea Healy <beahealy22@gmail.com>
Co-authored-by: Martin Erhart <maerhart@outlook.com>
Co-authored-by: Mike Urbach <mikeurbach@gmail.com>
Co-authored-by: Will Dietz <will.dietz@sifive.com>
Co-authored-by: fzi-hielscher <hielscher@fzi.de>
Co-authored-by: Fehr Mathieu <mathieu.fehr@gmail.com>
This fixes a PCM non-determinism regression reported here:
https://github.com/llvm/llvm-project/pull/134560#issuecomment-2797744370
There was a bit in `SubstNonTypeTemplateParmPackExpr` which we missed to
serialize, and that bit eventually propagates to
`SubstNonTypeTemplateParmExpr`.
As a drive by, improve serialization for PackIndex on
SubstNonTypeTemplateParmExpr by using the newly introduced
UnsignedOrNone helpers.
There are no release notes since this regression was never released.
Similar to #135415.
The spec has not strict restriction to allow a single `if_present`
clause on the host_data and update directives. Allowing this clause
multiple times does not change the semantic of it. This patch relax the
rules in ACC.td since there is no restriction in the standard.
The OpenACC dialect represents the `if_present` clause with a `UnitAttr`
so the attribute will be set if the is one or more `if_present` clause.
The spec has not strict restriction to allow a single `finalize` clause
on the `exit data` directive. Allowing this clause multiple times does
not change the semantic of it. This patch relax the rules in `ACC.td`
since there is no restriction in the standard.
The OpenACC dialect represent the finalize clause with a UnitAttr so the
attribute will be set if the is one or more `finalize` clause.
This change refines the verifier for `vector.load` and `vector.store` to
disallow the use of vectors with higher rank than the source or
destination memref. For example, the following is now rejected:
```mlir
%0 = vector.load %src[%c0] : memref<?xi8>, vector<16x16xi8>
vector.store %vec, %dest[%c0] : memref<?xi8>, vector<16x16xi8>
```
This pattern was previously used in SME end-to-end tests and "happened"
to work by implicitly assuming row-major memory layout. However, there
is no guarantee that such an assumption will always hold, and we should
avoid relying on it unless it can be enforced deterministically.
Notably, production ArmSME lowering pipelines do not rely on this
behavior. Instead, the expected usage (illustrated here with scalable
vector syntax) would be:
```mlir
%0 = vector.load %src[%c0, %c0] : memref<?x?xi8>, vector<[16]x[16]xi8>
```
This PR updates the verifier accordingly and adjusts all affected tests.
These tests are either removed (if no longer relevant) or updated to use
memrefs with appropriately matching rank.
This reverts commit e84a80408523a48d6eaacd795f1615e821ffb233 because on
Linux there seems to be a race around GetRunLock. See #134757 for more
context.
This reapplies commit
232525f069.
The original commit triggered a sanitizer failure when `Target` was
destroyed. In `Target::Destroy`, `DeleteCurrentProcess` was called, but
it did not destroy the thread creation breakpoints for the underlying
`ProcessGDBRemote` because `ProcessGDBRemote::Clear` was not called in
that path.
`Target `then proceeded to destroy its breakpoints, which resulted in a
call to the destructor of a `std::vector` containing the breakpoints.
Through a sequence of complicated events, destroying breakpoints caused
the reference count of the underlying `ProcessGDBRemote` to finally
reach zero. This, in turn, called `ProcessGDBRemote::Clear`, which
attempted to destroy the breakpoints. To do that, it would go back into
the Target's vector of breakpoints, which we are in the middle of
destroying.
We solve this by moving the breakpoint deletion into
`Process:DoDestroy`, which is a virtual Process method that will be
called much earlier.
fixes#135285
This change implements the `usub.sat` intrinsic to perform an unsigned
saturating subtraction on the 2 arguments.
The minimum value this operation is clamp to is 0.
At the moment the ftm macro for __cpp_lib_to_chars will have the
following values:
standard_ftms: {
"c++17": "201611L",
"c++20": "201611L",
"c++23": "201611L",
"c++26": "201611L",
}
implemented_ftms: {
"c++17": None,
}
This is an issue with the test whether the FTM is implemented it does:
self.implemented_ftms[ftm][std] == self.standard_ftms[ftm][std]
This will fail in C++20 since implemented_ftms[ftm] does not have the
key c++20. This adds a new helper function and removes the None entries
when a FTM is not implemented.
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
A few additions:
- Lines with `{{`: These can show up if serializing non-MLIR info into
string attrs `my.attr = {{proto}, {...}}`. String escape the opening
`{{`, given that check lines are generated this has no effect on
`{{.*}}` etc in generated lines.
- File split line: Normally these are skipped because of their indent
level, but if using `--starts_from_scope=0` to generate checks for the
`module {...} {` line, and since MLIR opt tools emit file split lines by
default, some `CHECK: // -----` lines were emit.
- (edit removed this, fixed by
https://github.com/llvm/llvm-project/pull/134364) AttrAliases: I'm not
sure if I'm missing something for the attribute parser to work
correctly, but I was getting many `#[[?]]` for all dialect attrs. Only
use the attr aliasing if there's a match.
The calleeDecl var will be used in the near future, so I left it. At
least for clang, the [[maybe_unused]] attribute takes care of the
warnings related to that variable. The other warning was a simple lack
of return after errorNYI.
This patch adds `VisitBinAssign` and `VisitBinComma` to the ClangIR
`ScalarExprEmitter` to enable assignments and the comma operator.
---------
Co-authored-by: Morris Hafner <mhafner@nvidia.com>
`Sema::getCurFunctionDecl(AllowLambda = false)` returns a nullptr when
the lambda declaration is outside a function (for example, when
assigning a lambda to a static constexpr variable).
This triggered an assertion in
`SemaAMDGPU::CheckAMDGCNBuiltinFunctionCall`.
Using `Sema::getCurFunctionDecl(AllowLambda = true)` returns the
declaration of the enclosing lambda.
Stumbled with this issue when refactoring some code in CK.
Fixes the case where subsequent passes were unable to find and delete
the invariant loop left over by the strlen idiom conversion. Since
`loop-deletion` only operate on computable loops, we can update the loop
condition to something more easily picked up by `loop-deletion`
As pointed out in https://github.com/llvm/llvm-project/issues/134736
