The vector.extract assembly format currently only contains the source
type, for example:
%1 = vector.extract %0[1] : vector<3x7x8xf32>
it's not immediately obvious if this is the source or result type. This
patch improves the assembly format to make this clearer, so the above
becomes:
%1 = vector.extract %0[1] : vector<7x8xf32> from vector<3x7x8xf32>
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
Power functions are implemented as linkonce_odr scalar functions
for FPowI operations met in a module.
Vector form of FPowI is linearized into a sequence of calls
of the scalar functions.
Option {min-width-of-fpowi-exponent} controls which FPowI operations
are converted by MathToFuncs: if the width of the exponent's integer
type is less than the specified value, then the operation is not converted.
Flang will specify {min-width-of-fpowi-exponent=33} to make sure that
math::FPowI operations with exponent wider than 32 bits will be converted
by MathToFuncs, and operations with more narrow exponent will be left
for MathToLLVM to convert them to LLVM::PowIOp.
Reviewed By: Mogball
Differential Revision: https://reviews.llvm.org/D139804
In D134622 the printed form of a pass manager is changed to include the
name of the op that the pass manager is anchored on. This updates the
`-pass-pipeline` argument format to include the anchor op as well, so
that the printed form of a pipeline can be directly passed to
`-pass-pipeline`. In most cases this requires updating
`-pass-pipeline='pipeline'` to
`-pass-pipeline='builtin.module(pipeline)'`.
This also fixes an outdated assert that prevented running a
`PassManager` anchored on `'any'`.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D134900
Power functions are implemented as linkonce_odr scalar functions
for integer types used by IPowI operations met in a module.
Vector form of IPowI is linearized into a sequence of calls
of the scalar functions.
Differential Revision: https://reviews.llvm.org/D129810
