[flang-commits] [clang] [flang] [Flang][FIR] Introduce FIRToCoreMLIR pass. (PR #168703)

[via flang-commits]

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