This revision starts an Arm-specific ArmNeon dialect discussed in the discourse RFC thread.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
23,400 ms | x64 debian > MLIR.Examples/standalone::test.toy |
Event Timeline
mlir/lib/Conversion/NeonToLLVM/ConvertNeonToLLVM.cpp | ||
---|---|---|
112 ↗ | (On Diff #307828) | This (and other parts) is directly taken from the AVX512 pass. For most part, that is okay with me, but this actually lowering part in AVX512 reflected in these lines of code did not compose very well with the regular vector dialect lowering (which has grown over time with e.g. contract lowering and friends). Perhaps we can make this part a bit more forward looking on how we want this to run. |
mlir/lib/Target/LLVMIR/LLVMNeonIntr.cpp | ||
10 ↗ | (On Diff #307828) | AVX -> Neon ;-) |
mlir/lib/Conversion/NeonToLLVM/ConvertNeonToLLVM.cpp | ||
---|---|---|
112 ↗ | (On Diff #307828) | As discussed in the syn meeting, let's not make this a full pass (and also remove the AVX512 pass), but simply keep this as "populate" methods that are pulled in on demand by the regular vector dialect pass. That will avoid copy-and-pasting the logic and avoid inconsistencies over time. The tests can have their own driver, they don't need a full pass either. As agreed, I will do the AVX512 pass removal in the meanwhile to set the right example. |
AVX512 restructuring landed as https://reviews.llvm.org/D92614
Let's follow that structure for all future architectural-dependent vector dialects....
mlir/include/mlir/Conversion/ArmNeonToLLVM/ArmNeonToLLVM.h | ||
---|---|---|
10 | I see a lint warning on this line. Not sure if it is useful? | |
mlir/include/mlir/Conversion/Passes.td | ||
404–407 | yes, this is a good point, we should only pull in what is needed | |
mlir/include/mlir/Dialect/ArmNeon/ArmNeonDialect.h | ||
3 | this line is way too long now |
mlir/include/mlir/Conversion/Passes.td | ||
---|---|---|
407 | Just don't add it here and implement the override method manually? That way you can check for the options. |
Did we actually get consensus around the direction here? I didn't see a clear conclusion.
clang-tidy: warning: header guard does not follow preferred style [llvm-header-guard]
not useful