mrkajetanp wrote: Pretty substantial redesign, I moved most of the logic into parse tree rewriting, I think this simplifies it and makes it more maintainable for the future. The rationale for the now-split design is as follows:
Most OpenMP constructs do not relate to simd at all, and so they can just be removed straight away. It is much cleaner to remove them in the parsing stage, because we still have all of the information on what the original code was. For instance, OpenMP loop constructs have a plain DoConstruct nested underneath them, so we can just use it directly. Once it gets lowered into an OpenMP loop, we would need to reverse the lowering which is a lot more brittle to maintain and keep in sync with the main lowering path. With the parse tree approach, the generated FIR will always be identical to `-fno-openmp`. Many other OpenMP constructs are BlockConstructs, which on the parse tree level can be processed in a uniform way without even knowing what the block is. With the current implementation, if someone adds a new type of OpenMP block, nothing will need to be updated for the flag to still work as expected with it. On the other hand, for composite simd constructs, the situation is the opposite. Constructs like "target teams distribute simd" are all one construct on the parse tree level, but are lowered into nested operations in MLIR. Trying to rewrite them into plain simd on the parse tree level would be brittle as well, and require a lot of special casing to make sure that we don't accidentally create a construct with illegal clauses that would then fail the semantic checks. With the MLIR pass, handling those nested operations is very straightforward. Keeping the MLIR pass also has the added benefit of having an extra check at the end that will complain to the user if any unexpected OpenMP ops are still left over at the end. I think this type of split design is the best way to make the flag maintainable, while trying to forcibly fit all the logic into either the MLIR or the parse tree would be more likely to cause problems down the line. https://github.com/llvm/llvm-project/pull/150269 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
