The upstream change to !llvm.ptr has triggered a lot of churn in the LLHD side of CIRCT. We currently don't rely on llhd-sim for anything in-tree. A few breakages remain in the interaction between the llhd-sim runtime and the generated code:
* test/Dialect/LLHD/Simulator/sim_formats.mlir
* test/Dialect/LLHD/Simulator/sim_process.mlir
* test/Dialect/LLHD/Simulator/sim_reg.mlir
* test/Dialect/LLHD/Simulator/sim_wait.mlir
These are now gated behind a REQUIRES: llhd-sim-fixed in order to unblock the LLVM bump and allow for them to be fixed in parallel. We might want to introduce a few intermediate ops in the LLHD dialect to reduce the pretty big abstraction gap between LLHD ops and LLVM. A lot of things can now go through the SCF dialect (and maybe memrefs?).
There were three breaking changes in LLVM:
1: In the LLVM dialect, NullOp was replaced with a more general ZeroOp. See:
https://github.com/llvm/llvm-project/pull/67183.
2: AffineForOp's getInitOperands was renamed to getInits. See:
https://github.com/llvm/llvm-project/pull/66925.
3: In the SCF dialect, the WhileOp now implements LoopLikeOpInterface, which
now supports multiple loop regions. The getLoopBody member-function was removed
in favour of LoopLike's getLoopRegions. The While Op only has a single region,
so we can replace calls to getLoopBody with getRegion. See:
https://github.com/llvm/llvm-project/pull/66754
Conversion patterns now have a `const` TypeConverter. Propagate this
through to methods which are expecting a non-const one.
This reflects changes here: https://reviews.llvm.org/D157601
Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
Instead users should use CombToArith+ArithToLLVM. There is still a pattern population function left for the comb.parity op, which does not have an equivalent in the arith dialect.
Only minor changes needed on our end:
* circt-translate: Update test to reflect supporting multiple translations.
* [LLHDtoLLVM] Continue not using opaque pointers.
* Drop useFoldAPI in Dialect ODS, only new method is supported now.
* Bump LLVM submodule
Minimal progress, but worth sharing.
* compiling now
* clang-format
* remove unnecessary includes from msft dialect
* XFAIL'ing broken Calyx tests
* Bump LLVM submodule
Minimal progress, but worth sharing.
* compiling now
* clang-format
* remove unnecessary includes from msft dialect
* XFAIL'ing broken Calyx tests
* Fix Calyx tests and ASAN, and re-enable. (#4592)
* Bump to 26th Jan
* switch to ninja and latest cmake
* hopefully fix ci builds
* use full path
* [circt-reduce] Set the default op for pass manager to builtin.module
---------
Co-authored-by: Andrew Young <youngar17@gmail.com>
Co-authored-by: Mike Urbach <mikeurbach@gmail.com>
Co-authored-by: Prithayan Barua <prithayan@gmail.com>
This bumps llvm just before 53406427cd which will cause a lot of complication failures about FunctionOpInterface. This PR mostly replaces llvm::None with std::nullopt.
Moves Comb to LLVM and HW to LLVM conversions out of the LLHDToLLVM pass and into their own dedicated lowering passes, as proposed in #3539.
The methods convertToLLVMEndianess and llvmIndexOfStructField are also encapsulated here within a HWToLLVMEndianessConverter class, in order to allow easier re-use between different passes.
Because LLHD uses operations from the cf dialect calling canonicalize creates, e.g., arith.select when control flow can be simplified. Canonicalization patterns of arith might then modify this further to arith.extui or similar. To be able to continue using the cf operations and benefit from all the control flow simplification canonicalizations, we need to add support for lowering arith operations to LLVM.
Since we have added operations to extract elements and slices from integers, signals, and pointers, and because the Moore compiler recently switched to not using these shifts anymore, we don't need these shift operations anymore to perform a dynamic extract. This also removes the weird corner case where two signals can be concatenated using these operations which are especially difficult to handle in the simulator.
We cannot directly switch to prefixed only because of the use of duck-typing in HWOpInterfaces.td and SVOps.cpp. This means we need to generate both the prefixed and non-prefixed accessors until all dialects that make use of HWInstanceLike have switched. This includes HW, SV, FIRRTL, MSFT.
* mlir::Identifier deprecated
* StringAttr::get(string, context) deprecated
* Many api changes in std dialect e.g. op.res() ==> op.getRes()
* getAsmBlockArgumentNames is moved to interface (https://reviews.llvm.org/D116018)
* populateFuncOpTypeConversionPattern =>
populateFunctionLikeOpTypeConversionPattern
* SmallVector::set_size() becomes private (https://reviews.llvm.org/D115380) replaced with resize()
* #dialect.mnemonic is elided by default https://reviews.llvm.org/D113873. For now, migrate by marking every type directive in asmFormat as qualified(https://reviews.llvm.org/D116905).
* Indices of LLVM::GEPOp are now required to be constant (https://reviews.llvm.org/D116759)
* [HW] Use StringAttr instead of StringRef in FieldInfo, nfc
This commit changes to use use StringAttr instead of StringRef
in FieldInfo to avoid unnecessary copies of field names.
Changes are mainly about parser/printer and CAPI.
This commit also changes Struct/UnionTypeImpl to use ArrayRefParameter
instead of ArrayRefOfSelfAllocationParameter in their tablegen
definition. And this deletes unnecessary allocators too.
Since MLIR has gained the `NoTerminator` op trait in the meantime,
remove the LLHD `TerminatorOp` that was originally introduced to get
around a lack of this trait. This requires adjusting the code in a few
places where the terminator is handled explicitly.
Bump LLVM to pull in performance improvements from
https://reviews.llvm.org/D111695.
This required the following fixes:
- Fix usages of deprecated matchAndRewrite member function that uses
an ArrayRef<Value>. Change this to use an OpAdaptor.
- Use Source Not Argument Materialization in HWToLLHD.
Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
Closes#1656 by removing the LLHD insert operations and replacing the extract operations as described in the issue.
Some notes/observations:
- Semantics of accessing out of bounds for both slices and single elements in LLHD were partially implemented to return a default value depending on the type (only for non-signal arrays in `llhd.dyn_extract_slice`) or UB. This PR defines it to be UB as this is also what HW does (I think).
- Field accesses to structs are checked, though.
- Extract slice operations cannot return a wider type (at most equal size), I think this is not the case in HW
- `llhd.sig.array_slice` does not work for a full slice of an array with one element (also `llhd.sig.extract` with signal of `i1`) as it requires a `i0` value as index, but this is not supported by `HWIntegerType` (e.g., `llhd.sig.array_slice %array at %index : (!llhd.sig<!hw.array<1xi32>>) -> !llhd.sig<!hw.array<1xi32>>`). A full slice, however, works for more elements in the array. `hw.array_slice` has the same behavior, I don't know if this is intended, or whether it should be enabled, or returning the same number of elements should be forbidden. Seems a bit inconsistent to me this way.
- Removed `sig` type support for `llhd.shr` in `LLHDToLLVM` as it was wrong in the first place (see #1988 ) and it lowered to an operation removed with this PR. It requires concatenating two signals in some way, this seems too complicated to quickly include in this PR.
Add support for HW aggregate operations in the LLHD simulator as preparation for #1653 and #1656 to avoid loosing simulator functionality.
Makes sure the endianess and bitcast semantics described in the rationale are followed. As HW uses big endian semantics and LLVM is machine dependent, the order of struct fields and array elements is reversed for little endian machines to match the in-memory layout. Big endian machines are not supported for now.
The lowering currently uses unpacked structs, however, HW structs are packed. This may lead to problems and should be fixed in a later PR (not included here as it adds a lot of noise).
Move singleton headers like circt/Conversion/LLHDToLLVM/LLHDToLLVM.h
up to circt/Conversion/LLHDToLLVM.h since that is the only thing in that
directory.
This updates LLVM to 704a395. We are pulling the new version of LLVM for the top commit which allows 0-bit APInts. This will help us model 0 bit constants in FIRRTL, and we will be able to properly use IntegerAttr as a (possibly 0-length) bitvector for FIRRTL port directions.
Included in this update is a change to the way `unrealized_conversion_casts` are handled by the LLVM converter infrastructure. We needed to update `LLHDToLLVM` to apply the new conversion casts. For more information see the public PSA on the LLVM discourse[^0].
This revealed a problem in the `LLHDToLLVM` where there was a failed to legalize operations in the lowering of `llhd.proc` and `llhd.entity`. These operation's lowering logic needed to ensure that operations from the (old) body of `llhd.proc` and `llhd.entity` were type converted before inserting new LLVM operations which used their results.
[0] https://llvm.discourse.group/t/psa-run-reconcile-unrealized-casts-after-all-convert-to-llvm-from-now-on/4266
Co-authored-by: Martin Erhart <maerhart@outlook.com>
Co-authored-by: Andrew Lenharth <andrew@lenharth.org>
Co-authored-by: Fabian Schuiki <fabian@schuiki.ch>
Co-authored-by: Andrew Young <youngar17@gmail.com>
Girish Pai