tblah wrote: > > If I understand correctly, any FIR type in the attribute will need to be > > convertible to an LLVM (MLIR dialect) type. Is that always the case? > > I might be mising something, but for which types that would not be the case? > The attribute stores the actual type on which the reduction operator will > apply so I think it should be convertible, otherwise that would mean the > compiler does not support reductions by-value on that type.
I think some time in the past, translation of a literal box (not a pointer to a box) from fir into LLVMIR (dialect) wasn't implemented. Boxes are weird because they have a different size depending on the rank (possibly only known at runtime) and whether the addendum is required. It may now be implemented. If you already tried all of the weirder fortran types and didn't crash the compiler then that's okay. > Shuffling reinterprets the data as bytes and moves the size of a type > regardless of what the type original was (see: > https://github.com/llvm/llvm-project/blob/main/llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp#L2454). Thanks for the explanation. I suspect that implementation won't work correctly in cases where the element size is only known dynamically. That's okay so long as we catch these cases and refuse to compile it instead of crashing the compiler or generating broken code. https://github.com/llvm/llvm-project/pull/165714 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
