================ @@ -0,0 +1,53 @@ +//===-- CIRStdOps.td - CIR standard library ops ------------*- 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 +// +//===----------------------------------------------------------------------===// +/// +/// Defines ops representing standard library calls, raised from plain calls +/// by the cir-idiom-recognizer pass and lowered back by LoweringPrepare. +/// +//===----------------------------------------------------------------------===// + +#ifndef CLANG_CIR_DIALECT_IR_CIRSTDOPS_TD +#define CLANG_CIR_DIALECT_IR_CIRSTDOPS_TD + +// knownKind names the CIR_KnownFuncKind entry whose tagged calls raise +// to this operation. +class CIR_StdOp<string functionName, dag args, dag res, + list<Trait> traits = [], string knownKind = ""> + : CIR_Op<"std." # functionName, traits> { + let arguments = !con(args, (ins FlatSymbolRefAttr:$original_fn)); + let results = res; + let hasLLVMLowering = false; + + let extraClassDeclaration = [{ + static constexpr unsigned getNumArgs() { + return }] # !size(args) # [{; ---------------- SharmaRithik wrote:
Ah I see, thanks for clarifying. Yes, that is the approach. The two operations share one identity kind and the recognizer picks between them by argument count, which I confirmed on a build with two operations of different arities under one kind. For std::vector::erase that shared identity would come from the class enum on the other thread, since erase alone is also a member of other containers, and both of vector's erase overloads would carry that one identity. https://github.com/llvm/llvm-project/pull/208854 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
