[PATCH] D114159: [flang][codegen] Add a conversion for `fir.coordinate_of` - part 1
Andrzej Warzynski via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Nov 29 10:31:43 PST 2021
awarzynski added inline comments.
================
Comment at: flang/lib/Optimizer/CodeGen/CodeGen.cpp:2323
+ rewriter.create<mlir::LLVM::GEPOp>(
+ loc, mlir::LLVM::LLVMPointerType::get(llvmEleTy), args);
+ }
----------------
clementval wrote:
> rovka wrote:
> > This still doesn't seem quite right. How are all these GEPs used? It seems you're just creating them, but then you're replacing the original coor with objectBaseAddr, so you're just going around the GEPs (i.e. the users of the coor will get objectBaseAddr instead of a GEP based on objectBaseAddr).
> >
> Please double check in `fir-dev` when you change code like that.
@rovka
Good point, thanks! Also, your comment made me realise that I misunderstood how `fir.coordinate_of` is meant to work for `fir.type` and `fir.array`. In particular, `fir.type` could contain `fir.array` and vice versa. This is catered for on `fir-dev` (see [[ https://github.com/flang-compiler/f18-llvm-project/blob/fir-dev/flang/lib/Optimizer/CodeGen/CodeGen.cpp#L2158-L2207 | here ]] ), but was incorrectly split into "orthogonal" cases by me in this patch. I will revert that and restore one big case for `fir.type`/`fir.array` instead.
And yes, this "rewrite" should replace the original OP with a GEP. In theory :) There's a bunch of bitcasts too as `fir.array` and `fir.type` cases are a bit different. So, ultimately, it might be an `llvm.bitcast` applied to a result of `llvm.getelemenptr`.
> Please double check in fir-dev when you change code like that.
Checked, all good 👍🏻 !
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D114159/new/
https://reviews.llvm.org/D114159
More information about the llvm-commits
mailing list