jeanPerier wrote:
> If I understand Jean correctly he suggest implemeting the
> `MemorySlotInterfaces.td` for [HL]FIR operations and running `Mem2Reg` in
> Flang pipeline.
Yes, that is what I would want to be able to do. @NexMing, thanks for being
willing to help! I think the first step is to validate that the idea is
possible. There are some differences between fir.declare and llvm.dbg.declare,
the most relevant one being that fir.declare returns a result, and I think that
fir.declare_value should not:
We want:
```
func.func @test(%x : f32) {
%temp = fir.alloca f32
fir.store %x to %temp
%decl = fir.declare %temp {uniq_name=....}
%val = fir.load %decl
fir.call bar(%val)
}
```
To become:
```
func.func @test(%x : f32) {
fir.declare_value %x {uniq_name=....}
fir.call bar(%x)
}
```
And not the following that would break further folding optimization of SSA
values.
```
func.func @test(%x : f32) {
%x_decl = fir.declare_value %x {uniq_name=....}
fir.call bar(%x_decl)
}
```
I am hoping the MLIR interfaces allow for this, but I did not check (if it is
blocking, I guess we could still solve this by having a result to
fir.declare_value and having a canonicalization pattern that match any
operation where an operand is produced by it and replace it).
Other points to consider is how to rewrite `fir.declare fir.ref<fir.box<>>`
(POINTER and ALLOCATABLE) after resolving the target. The target is still an
address/variable, so these ones should probably be rewritten to `fir.declare
fir.box` with an update of the variable attributes (allocatable attribute
should be dropped and pointer attribute turned into a target attribute +
probably some new special attribute to help debug info generation understanding
what happened).
I am also expecting that after mem2reg we may hit some over assertive FIR
verifier that are checking constant value inputs range/values, which is a nice
intention, but will break valid code where such operation are not reachable at
runtime. So we will likely need to do a few clean-ups before enabling it in the
pipeline, but this does not prevent from starting to add the
MemorySlotInterfaces to FIR operations.
> if I revert the handling of fir.cg, do you think the current PR is still
> worth submitting (it seems to overlap with your work)?
I think it will overlap and sometimes in slightly incompatible ways because our
approach currently is to use fir.convert as the interfacing op between memref
and fir types, not builtin.unrealized_conversion_cast. Sorry for the
inconvenience, I look forward to collaborate on it as soon as we send it for
review.
https://github.com/llvm/llvm-project/pull/168703
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
