`fir.embox` lowering produces invalid IR during `fir-to-llvm-ir`

[matthias-springer]

I noticed that fir-opt produces invalid IR during fir-to-llvm-ir for this test case:

fir.global @elesize_of_embox constant : i32 {
  %0 = fir.zero_bits !fir.ptr<i32>
  %1 = fir.embox %0 : (!fir.ptr<i32>) -> !fir.box<!fir.ptr<i32>>
  %2 = fir.box_elesize %1 : (!fir.box<!fir.ptr<i32>>) -> i32
  fir.has_value %2 : i32
}

Error:

within split at llvm-project/flang/test/Fir/convert-to-llvm.fir:1 offset :4:8: error: ops with side effects not allowed in global initializers
  %2 = fir.box_elesize %1 : (!fir.box<!fir.ptr<i32>>) -> i32
       ^
within split at llvm-project/flang/test/Fir/convert-to-llvm.fir:1 offset :4:8: note: see current operation: %23 = "llvm.load"(%22) <{ordering = 0 : i64}> : (!llvm.ptr) -> i64

This is only one of the problems. The dialect conversion also inserts an unrealized_conversion_cast from the boxed ptr to a bare pointer:

  "llvm.mlir.global"() <{addr_space = 0 : i32, constant, global_type = i32, linkage = #llvm.linkage<external>, sym_name = "elesize_of_embox", visibility_ = 0 : i64}> ({
    %0 = "llvm.mlir.zero"() : () -> !llvm.ptr
    %1 = "llvm.mlir.constant"() <{value = 9 : i32}> : () -> i32
    %2 = "llvm.mlir.zero"() : () -> !llvm.ptr
    %3 = "llvm.getelementptr"(%2) <{elem_type = i32, rawConstantIndices = array<i32: 1>}> : (!llvm.ptr) -> !llvm.ptr
    %4 = "llvm.ptrtoint"(%3) : (!llvm.ptr) -> i64

    ...

    %20 = "llvm.insertvalue"(%19, %0) <{position = array<i64: 0>}> : (!llvm.struct<(ptr, i64, i32, i8, i8, i8, i8)>, !llvm.ptr) -> !llvm.struct<(ptr, i64, i32, i8, i8, i8, i8)>
    %21 = "builtin.unrealized_conversion_cast"(%20) : (!llvm.struct<(ptr, i64, i32, i8, i8, i8, i8)>) -> !llvm.ptr
    %22 = "llvm.getelementptr"(%21) <{elem_type = !llvm.struct<(ptr, i64, i32, i8, i8, i8, i8)>, rawConstantIndices = array<i32: 0, 1>}> : (!llvm.ptr) -> !llvm.ptr
    %23 = "llvm.load"(%22) <{ordering = 0 : i64}> : (!llvm.ptr) -> i64
    %24 = "llvm.trunc"(%23) <{overflowFlags = #llvm.overflow<none>}> : (i64) -> i32
    "llvm.return"(%24) : (i32) -> ()
  }) : () -> ()

Within fir.global, fir.embox does not lower to an alloca but directly to an LLVM struct. This does not compose with the remaining ops. I think the only thing you can do is returning the boxed values via fir.has_value, everything else produces invalid IR.

Why does Flang store the LLVM struct that is generated during "boxing" in a stack allocation? Why not use the LLVM struct directly? In the type converter, there is convertBoxType and convertBoxTypeAsStruct. Why isn't convertBoxTypeAsStruct used everywhere?

Context: I am looking at this as part of refactorings of the dialect conversion framework and ran into issues with HasValueOpConversion and InsertValueOpConversion (in CodeGen.cpp). Ideally, these should run with a type converter. I'm trying to understand what's the right solution here.

[jeanPerier]

The short story is that we wanted the descriptor to be SSA values but could not because the Fortran descriptor (the struct you are seeing) can have dynamic size, so we went with fir.box being implemented like a uniq constant pointer and just worked around the few places where this implementation was problematic (which are contexts where the descriptor cannot be dynamically sized).

It is clear this needs a redesign, FIR types with contexts dependent lowering were a bad idea (this interacts poorly with the genericity of MLIR), this will likely be an extensive change because the type is used extensively (this is FIR memref like type).

I am currently thinking about how best to change the design, but it is hard to commit to a quick fix here. Would the workaround I pointed you to would solve your refactoring problem in the short term if applied to some other patterns like the one you mentioned?

[llvmbot]

@llvm/issue-subscribers-flang-ir

Author: Matthias Springer (matthias-springer)

I noticed that `fir-opt` produces invalid IR during `fir-to-llvm-ir` for this test case:

fir.global @<!-- -->elesize_of_embox constant : i32 {
  %0 = fir.zero_bits !fir.ptr&lt;i32&gt;
  %1 = fir.embox %0 : (!fir.ptr&lt;i32&gt;) -&gt; !fir.box&lt;!fir.ptr&lt;i32&gt;&gt;
  %2 = fir.box_elesize %1 : (!fir.box&lt;!fir.ptr&lt;i32&gt;&gt;) -&gt; i32
  fir.has_value %2 : i32
}

Error:

within split at llvm-project/flang/test/Fir/convert-to-llvm.fir:1 offset :4:8: error: ops with side effects not allowed in global initializers
  %2 = fir.box_elesize %1 : (!fir.box<!fir.ptr<i32>>) -> i32
       ^
within split at llvm-project/flang/test/Fir/convert-to-llvm.fir:1 offset :4:8: note: see current operation: %23 = "llvm.load"(%22) <{ordering = 0 : i64}> : (!llvm.ptr) -> i64

This is only one of the problems. The dialect conversion also inserts an unrealized_conversion_cast from the boxed ptr to a bare pointer:

  "llvm.mlir.global"() <{addr_space = 0 : i32, constant, global_type = i32, linkage = #llvm.linkage<external>, sym_name = "elesize_of_embox", visibility_ = 0 : i64}> ({
    %0 = "llvm.mlir.zero"() : () -> !llvm.ptr
    %1 = "llvm.mlir.constant"() <{value = 9 : i32}> : () -> i32
    %2 = "llvm.mlir.zero"() : () -> !llvm.ptr
    %3 = "llvm.getelementptr"(%2) <{elem_type = i32, rawConstantIndices = array<i32: 1>}> : (!llvm.ptr) -> !llvm.ptr
    %4 = "llvm.ptrtoint"(%3) : (!llvm.ptr) -> i64

    ...

    %20 = "llvm.insertvalue"(%19, %0) <{position = array<i64: 0>}> : (!llvm.struct<(ptr, i64, i32, i8, i8, i8, i8)>, !llvm.ptr) -> !llvm.struct<(ptr, i64, i32, i8, i8, i8, i8)>
    %21 = "builtin.unrealized_conversion_cast"(%20) : (!llvm.struct<(ptr, i64, i32, i8, i8, i8, i8)>) -> !llvm.ptr
    %22 = "llvm.getelementptr"(%21) <{elem_type = !llvm.struct<(ptr, i64, i32, i8, i8, i8, i8)>, rawConstantIndices = array<i32: 0, 1>}> : (!llvm.ptr) -> !llvm.ptr
    %23 = "llvm.load"(%22) <{ordering = 0 : i64}> : (!llvm.ptr) -> i64
    %24 = "llvm.trunc"(%23) <{overflowFlags = #llvm.overflow<none>}> : (i64) -> i32
    "llvm.return"(%24) : (i32) -> ()
  }) : () -> ()

Within fir.global, fir.embox does not lower to an alloca but directly to an LLVM struct. This does not compose with the remaining ops. I think the only thing you can do is returning the boxed values via fir.has_value, everything else produces invalid IR.

Why does Flang store the LLVM struct that is generated during "boxing" in a stack allocation? Why not use the LLVM struct directly? In the type converter, there is convertBoxType and convertBoxTypeAsStruct. Why isn't convertBoxTypeAsStruct used everywhere?

Context: I am looking at this as part of refactorings of the dialect conversion framework and ran into issues with HasValueOpConversion and InsertValueOpConversion (in CodeGen.cpp). Ideally, these should run with a type converter. I'm trying to understand what's the right solution here.

[matthias-springer]

but could not because the Fortran descriptor (the struct you are seeing) can have dynamic size

What does that mean exactly? When you see a fir type, do you not know which LLVM struct to convert it to without looking at the IR (or having some kind of runtime information)? Can you give me an example?

This reminds me a bit of MemRef -> LLVM type conversion in MLIR...

I am currently thinking about how best to change the design, but it is hard to commit to a quick fix here. Would the workaround I pointed you to would solve your refactoring problem in the short term if applied to some other patterns like the one you mentioned?

I don't think this is blocking my work, I'm confident that we can find some workaround. Probably something like the code that you pointed to. I just wanted to make sure that you are aware of the issue and for me to understand what the ideal design would be. (Maybe we can go a bit into that direction when there are multiple possible workarounds.)

[jeanPerier]

What does that mean exactly? When you see a fir type, do you not know which LLVM struct to convert it to without looking at the IR (or having some kind of runtime information)? Can you give me an example?

In a few cases, yes. The size of the array descriptor used by flang depends on the rank of the array (the runtime data structure contains a flexible array to describe the dimensions, as requested by the Fortran standard). There is an "assumed-rank" type in Fortran for which the rank is not known at compile time. So in FIR, it is not known statically what is the size of the struct for fir.box<fir.array<*:f32>> andcomputeBoxSize has to be used in those cases to generate operations to compute the size.

Fortran polymorphic types may also lead to a few similar scenario in the future because of Fortran derived type length parameters (not yet supported by flang lowering).

Both assumed-rank and polymorphic entities cannot be met in globalOp initializers, where fir.box manipulation is only generated to deal with Fortran pointer initial target, and these initial targets cannot be assumed-rank/polymorphic.