[llvm-branch-commits] [clang] [CIR][NFC] Add scaffolding for the CIR dialect and CIROps.td (PR #86080)

[Aaron Ballman via llvm-branch-commits]

================
@@ -0,0 +1,44 @@
+//===- CIRDialect.td - CIR dialect -------------------------*- tablegen -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+//
+// This file declares the CIR dialect.
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef LLVM_CLANG_CIR_DIALECT_IR_CIRDIALECT
+#define LLVM_CLANG_CIR_DIALECT_IR_CIRDIALECT
+
+include "mlir/IR/OpBase.td"
+
+def CIR_Dialect : Dialect {
+  let name = "cir";
+
+  // A short one-line summary of our dialect.
+  let summary = "A high-level dialect for analyzing and optimizing Clang "
+                "supported languages";
+
+  let cppNamespace = "::mlir::cir";
+
+  let useDefaultAttributePrinterParser = 0;
+  let useDefaultTypePrinterParser = 0;
+
+  let extraClassDeclaration = [{
+    void registerAttributes();
+    void registerTypes();
+
+    Type parseType(DialectAsmParser &parser) const override;
----------------
AaronBallman wrote:

> This will be added to generated class which have lower-case starting APIs: consistency within the class seems to prevail to me.

Ah, then yeah, I agree. Thank you!

> You should really expect that all the MLIR code will follow this convention, because it'll be intertwined closely with the MLIR framework.

MLIR isn't old enough to really get "grandfathered" in with their own style, so that's pretty surprising. That said, I *fully support* letting projects have project-specific policies including coding style, so I see no reason for MLIR to change either. Interfacing closely with MLIR does make this a bit awkward however, because it's also intertwined with the Clang code base. On balance, I think it's fine to follow the MLIR convention because I think there will be more surface area in common between CIR + MLIR than CIR + Clang (and Clang has plenty of inconsistency with coding style already so this is not really novel).

tl;dr: nothing needs to change here.

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