This avoids pulling in function converion patterns, which is not
part of what we want to test in ArithmeticToSPIRV. It also allows
using ConvertArithmeticToSPIRVPass as a standalone step.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/Conversion/ArithmeticToSPIRV/ArithmeticToSPIRV.cpp | ||
---|---|---|
881–889 | should this go in the type converter so that all the convertToSPIRV pass would have it? |
mlir/lib/Conversion/ArithmeticToSPIRV/ArithmeticToSPIRV.cpp | ||
---|---|---|
881–889 | That would mean to force all downstream passes to accept the unrealized_conversion_cast as a legal op and allow generating them. I'd prefer to actually give the option to downstream passes cause that's where we pull all patterns together, so we have the flexibility to either use one pass to convert all or use multiple passes to bridge the conversion step by step. These few lines of code will be duplicated for sure but I think it's okay. |
mlir/lib/Conversion/ArithmeticToSPIRV/ArithmeticToSPIRV.cpp | ||
---|---|---|
881–889 | ok, I don't have a strong opinion but since this is how convert to llvm does it I thought it would make sense to match it. In my experience it is convenient to see the unrealized cast that didn't get eliminated when looking for ops that have not been lowered but that's subjective. |
mlir/lib/Conversion/ArithmeticToSPIRV/ArithmeticToSPIRV.cpp | ||
---|---|---|
881–889 | I see your points. Yeah that's reasonable too. Anyway, not a big issue; we can change it later. :) |
should this go in the type converter so that all the convertToSPIRV pass would have it?