bcardosolopes wrote: Thanks for everyone's input so far. Let me try to summarize two discussions in this PR so we can set on an approach and give advice to our CIR community (and encode on our webpage) on how to move forward in upcoming patches. Useful resources: - [LLVM Coding Standard](https://llvm.org/docs/CodingStandards.html) - [MLIR Style Guide](https://mlir.llvm.org/getting_started/DeveloperGuide/#style-guide)
CC'ing more people who might care: @seven-mile, @Lancern. ## Use of `auto` As @joker-eph mentioned, MLIR isn't meant to differ from LLVM/Clang, though they encode the differences as part of their guidelines. The `auto` [guidance](https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable) is still in favor of us keeping it for all `isa`, `dyn_cast` and `cast`, which is used in CIR, so it probably doesn't affect most of what we currently care about. Here's my suggestion for the entire `lib/CIR`: 1. Use it for function templates such as `isa`, `dyn_cast`, `cast`, `create` and `rewriteOp.*` variants. 2. Use it for things considered obvious/common in MLIR space, examples: - `auto loc = op->getLoc()`. - Getting operands and results from operations (they obey Value Semantics), e.g.: `DepthwiseConv2DNhwcHwcmOp op; ...; auto stride = op.getStrides();` - Other examples we are happy to provide upon reviewer feedback if it makes sense. Using the logic above, all `auto`s in this current PR have to be changed (since none apply). ## Namings: CamelCase vs camelBack >From this discussion, seems like @AaronBallman and @erichkeane are fine with >us using camelBack and all the other differences from [MLIR Style >Guide](https://mlir.llvm.org/getting_started/DeveloperGuide/#style-guide) in >CIRGen and the rest of CIR. Is that right? This is based on the comment: > The mixed naming conventions in the header should be fixed (preference is to > follow LLVM style if we're changing code around, but if the local preference > is for MLIR, that's fine so long as it's consistent). However, @AaronBallman also wrote: > Also, the fact that the naming keeps being inconsistent is a pretty strong > reason to change to use the LLVM naming convention, at least for external > interfaces. Should we ignore this in light of your first comment? If not, can you clarify what do you mean by external interfaces? Just want to make sure we get it right looking fwd. Does this makes sense? Thoughts? https://github.com/llvm/llvm-project/pull/91007 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
