[flang-commits] [flang] [flang] lower std::complex value argument to tuple<f, f> (PR #110643)

via flang-commits flang-commits at lists.llvm.org
Tue Oct 1 07:38:14 PDT 2024


jeanPerier wrote:

> I'm not familiar with the exact ABI of the mlir::TupleType, do they guarantee that it has the same ABI as a struct with the same members? I assume that is what it is underneath.

It lowers to `{ float, float }` in LLVM IR. I can't guarantee this is OK on all ABIs. MLIR is not really equipped to deal with aggregate by value ABIs. As you mentioned, we should rather stay away from this altogether.

> On second thought, should we possibly remove the by-value models entirely? I think those will only cause issues.

I agree with you here. It is currently only required for the REDUCE intrinsics, and more specifically for the callback signature. I think it is most likely a runtime bug since the callback is defined in Fortran, so I opened [an issue](https://github.com/llvm/llvm-project/issues/110674).

> For an example off the top of my head, `std::complex<float>` and `struct {float; float;};` do not have the same return value ABI on Windows.

I know this is true for _Complex vs `struct {float; float;};`, but the C++ standard defines std::complex as _class_ template that is storage compatible with `struct {float; float;}`. So if it is a class, it falls into the same ABI rules as a struct as far as I know. On 32 bit machine where _Complex and std::complex ABI differ, `std::complex` and `struct {float; float;};` are lowered the same way in intefaces (see [this godbolt example](https://godbolt.org/z/fvfsjb6ne)). Anyway, I agree with your point that it is best to stay away from it.

https://github.com/llvm/llvm-project/pull/110643


More information about the flang-commits mailing list