banach-space wrote: Hi folks, thanks for the feedback, and sorry for the delay getting back to this.
It sounds like there is general agreement that having a place for shared code would be useful, but it’s not yet clear what that place should be. I don’t have a strong opinion myself—I’m still relatively new to ClangIR and would like a bit more time to see what common patterns emerge. As a data point, here are some examples from MLIR. Many dialects there include a Utils.cpp file, for example: * https://github.com/llvm/llvm-project/blob/main/mlir/lib/Dialect/Affine/Utils/Utils.cpp * https://github.com/llvm/llvm-project/blob/main/mlir/lib/Dialect/Linalg/Utils/Utils.cpp * https://github.com/llvm/llvm-project/blob/main/mlir/lib/Dialect/Vector/Utils/VectorUtils.cpp One benefit of this approach is that it provides a clear home for shared functionality that doesn’t obviously belong anywhere else. This is how I’m thinking about the newly added file in this PR. > We could also consider making this particular function a member of > CIRGenBuilderTy. This raises a broader question for me about the intended role of `CIRGenBuilderTy`. It already contains a number of “op builder” helpers, but some of them (e.g. [createVecShuffle](https://github.com/llvm/llvm-project/blob/188507e54218c91832714fc50b24bd2fc2fd9383/clang/lib/CIR/CodeGen/CIRGenBuilder.h?plain=1#L643-L651) ) only require access to a builder - similar to the proposed `emitIntrinsicCallOp` that I am adding here. I’m not arguing against placing this functionality in `CIRGenBuilderTy`; rather, I’m trying to better understand the design intent and where the line is drawn. Any guidance or pointers would be very helpful 😅 Thanks! https://github.com/llvm/llvm-project/pull/172735 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
