This revision adds an additional `reifyValueBounds` helper that reifies the IR with Arith ops instead of Affine ops. This is needed to support value bounds for integer types different from `index` in a subsequent revision.
Differential Revision: https://reviews.llvm.org/D146524
The `clang:ast` and `clang:builtin_headers_gen` targets currently use hardcoded `external/llvm-project`
paths to access generated headers.
With bzlmod this path becomes dependent on the module name, module version and module extension,
so we need a more dynamic approach.
Does not affect the WORKSPACE build.
Reviewed By: GMNGeoffrey, #bazel_build
Differential Revision: https://reviews.llvm.org/D137007
With the recent move away from StringStream some tests were given a
dependency on cpp::string. Some of these were missed for the bazel
build, causing build failures.
Differential Revision: https://reviews.llvm.org/D148572
When running `arc diff` on a newly added file,
utils/arcanist/clang-format.sh is run. For new files there is no change,
but the script will bail. Without the use of the -f flag, we get
interactive prompts like:
rm: remove write-protected regular file '/tmp/tmp.ReMybrBw35'?
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D148555
- Implement `VTEmitter` as `llvm-tblgen -gen-vt`.
- Create a copy of `llvm/Support/MachineValueType.h` into `unittests/Support`.
It includes `GenVT.inc` generated by `VTEmitter`.
- Implement `MVTTest` in `SupportTests`. It checks equivalence between
`llvm/Support/MachineValueType.h` and the generated header.
Differential Revision: https://reviews.llvm.org/D146906
Add a set of transform operations into the "structured" extension of the
Transform dialect that allow one to select transformation targets more
specifically than the currently available matching. In particular, add
the mechanism for identifying the producers of operands (input and init
in destination-passing style) and users of results, as well as
mechanisms for reasoning about the shape of the iteration space.
Additionally, add several transform operations to manipulate parameters
that could be useful to implement more advanced selectors. Specifically,
new operations let one produce and compare parameter values to implement
shape-driven transformations.
New operations are placed in separate files to decrease compilation
time. Some relayering of the extension is necessary to avoid repeated
generation of enums.
Depends on D148013
Depends on D148014
Depends on D148015
Reviewed By: chelini
Differential Revision: https://reviews.llvm.org/D148017
Add a new transform op combinator that implements an "if-then-else"
style of mechanism for applying transformations. Its main purpose is to
serve as a higher-level driver when applying multiple transform scripts
to potentially overlapping pieces of the payload IR. This is similar to
how the various rewrite drivers operate in C++, but at a higher level
and with more declarative expressions. This is not intended to replace
existing pattern-based rewrites, but to to drive more complex
transformations that are exposed in the transform dialect and are too
complex to be expressed as simple declarative rewrites.
Reviewed By: springerm
Differential Revision: https://reviews.llvm.org/D148013
Introduce the `memmem` libc string function.
`memmem_implementation` performs shared logic for `strstr`,
`strcasestr`, and `memmem`; essentially reconfiguring what was the
`strstr_implementation` to support length parameters.
Differential Revision: https://reviews.llvm.org/D147822
Use `reifyValueBound` instead, which is more general not hard-coded to a specific list supported ops.
Also add a `closedUB` parameter to the ValueBoundsOpInterface API.
Differential Revision: https://reviews.llvm.org/D146356
Followup to D147354. Using src/conditions is discouraged in favor of using rules from the `@platforms` repository directly.
This replaces three conditions:
* `@bazel_tools//src/conditions:windows` -> `@platforms//os:windows`
* `@bazel_tools//src/conditions:darwin` -> `@platforms//os:macos`
* `@bazel_tools//src/conditions:freebsd` -> `@platforms//os:freebsd`
`llvm/config.bzl` has a non-trivial OS+CPU selection config, so that is omitted from this patch. There is intentionally no equivalent for that in `@platforms` because every project will have their own opinions about what a platform is, and it is not feasible for the bazel selection list to include every possible combination. The recommended idiom there is for projects to define their own supported platforms list, e.g. in a separate BUILD file or platform mapping.
Reviewed By: GMNGeoffrey
Differential Revision: https://reviews.llvm.org/D147948
This change adds a software implementation of the `math.ctlz` operation
and includes it in `--convert-math-to-funcs`.
This is my first change to MLIR, so please bear with me as I'm still learning
the idioms of the codebase.
The context for this change is that I have some larger scale project in which
I'd like to lower from a mix of MLIR dialects to CIRCT, but many of the CIRCT
passes don't support the `math` dialect.
I noticed the content of `convert-math-to-funcs` was limited entirely to
the `pow` functions, but otherwise provided the needed structure to implement
this feature with minimal changes.
Highlight of the changes:
- Add a dependence on the SCF dialect for this lower. I could have lowered
directly to cf, following the pow lowerings in the same pass, but I felt it
was not necessary given the existing support for lowering scf to cf.
- Generalize the DenseMap storing op implementations: modify the callback
function hashmap to be keyed by both OperationType (for me this effectively
means the name of the op being implemented in software) and the type
signature of the resulting function.
- Implement the ctlz function as a loop. I had researched a variety of
implementations that claimed to be more efficient (such as those based on a
de Bruijn sequence), but it seems to me that the simplest approach would make
it easier for later compiler optimizations to do a better (platform-aware)
job optimizing this than I could do by hand.
Questions I had for the reviewer:
- [edit: found mlir-cpu-runner and added two tests] What would I add to the filecheck invocation to actually run the resulting MLIR on a value and assert the output is correct? I have done this manually with the C implementation but I'm not confident my port to MLIR is correct.
- Should I add a test for a vectorized version of this lowering? I followed suit with the ` VecOpToScalarOp` but I admit I don't fully understand what it's doing.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D146261
If an `scf.for` loop yields an equal index-typed value or a shaped value with the same dimension sizes (in comparison to the corresponding iter_arg), bounds can be computed for the iter_arg and the OpResult of the `scf.for` op.
Differential Revision: https://reviews.llvm.org/D146306
Ops can implement this interface to specify lower/upper bounds for their result values and block arguments. Bounds can be specified for:
* Index-type values
* Dimension sizes of shapes values
The bounds are added to a constraint set. Users can query this constraint set to compute bounds wrt. to a user-specified set of values. Only EQ bounds are supported at the moment.
This revision also contains interface implementations for various tensor dialect ops, which illustrates how to implement this interface.
Differential Revision: https://reviews.llvm.org/D145681
This implements a proof-of-concept GPU code generator
to the sparse compiler pipeline, currently only capable
of generating CUDA threads for outermost parallel loops.
The objective, obviously, is to grow this concept
to a full blown GPU code generator, capable of the
right combinaton of code generation as well as exploiting
idiomatic kernels or vector specific libraries (think cuSparse).
Reviewed By: ThomasRaoux
Differential Revision: https://reviews.llvm.org/D147483
