================ @@ -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 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
