The upstreamed code was not incrementing the sliceOffset in multiples
of 3. This issue is fixed by using Offsets and incrementing by 3 during
every iteration.
In the conversion pattern, we were comparing the definingOp of an
operand with an FIR::UndefOp. Use LLVM::UndefOp for conversion.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
This increment was upstreamed correctly but it was removed by https://reviews.llvm.org/D125967.
Otherwise LGTM.
Ahh, I see. Now I understand why that code was in the original way. I guess it was to check with the fir::UndefOp.
flang/lib/Optimizer/CodeGen/CodeGen.cpp | ||
---|---|---|
2107 | I have opened a discussion in https://discourse.llvm.org/t/order-of-conversion-of-operations/63259 for checking whether comparing with LLVM::UndefOp is the correct way. It seems it is not entirely safe to do that comparison. May be we should do the comparison on the original Operands, and create step with the converted operands. But I am getting a crash with the getDefiningOp call in some cases with the original Operand. |
Use the originalOperands to check whether it is an fir::UndefOp
instead of using the newOperands and checking whether it is an
LLVM::UndefOp.
Ahh, I see. Now I understand why that code was in the original way.
+1. Sorry for the previous incorrect remove. I go through the conversion of fir::cg::XArrayCoorOp and have several nit comments. In addition, operands[0] is commonly used, should it be assigned to one variable coorBaseAddr/coorBase similar to the conversion of fir::CoordinateOp so to make it more readable? @kiranchandramohan Can you commit one NFC for these changes if they look OK to you?
flang/lib/Optimizer/CodeGen/CodeGen.cpp | ||
---|---|---|
2125 | ||
2145 | ||
2147 | ||
2193 | ||
2202 | ||
2206 | ||
2214 |
I have opened a discussion in https://discourse.llvm.org/t/order-of-conversion-of-operations/63259 for checking whether comparing with LLVM::UndefOp is the correct way. It seems it is not entirely safe to do that comparison.
May be we should do the comparison on the original Operands, and create step with the converted operands. But I am getting a crash with the getDefiningOp call in some cases with the original Operand.