Differential D129810 Diff 455451 mlir/include/mlir/Conversion/MathToFuncs/MathToFuncs.h

Changeset View

Standalone View

View Options

mlir/include/mlir/Conversion/MathToFuncs/MathToFuncs.h

This file was added.

//===- MathToFuncs.h - Math to outlined impl conversion ---------*- C++ -*-===//

// 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

//===----------------------------------------------------------------------===//

#ifndef MLIR_CONVERSION_MATHTOFUNCS_MATHTOFUNCS_H

#define MLIR_CONVERSION_MATHTOFUNCS_MATHTOFUNCS_H

#include <memory>

MogballUnsubmitted

Done

You can remove this include

Mogball: You can remove this include

namespace mlir {

class Pass;

// Pass to convert some Math operations into calls of functions

MogballUnsubmitted

Done

#include <memory>

namespace mlir {

class Pass;

// Pass to convert some Math operations into calls of functions

Mogball:

// containing software implementation of these operations.

std::unique_ptr<Pass> createConvertMathToFuncsPass();

} // namespace mlir

#endif // MLIR_CONVERSION_MATHTOFUNCS_MATHTOFUNCS_H

MogballUnsubmitted

Done

These functions normally return just a Pass

Mogball: These functions normally return just a `Pass`

vzakhariAuthorUnsubmitted

Done

I see that many-many passes that are defined as ModuleOp passes in mlir/lib/Conversion/Passes.td (i.e. they are derived from Pass<"...", "ModuleOp">) all return std::unique_ptr<OperationPass<ModuleOp>> in the CPP files in mlir/lib/Conversion/*/*.cpp. I am not comfortable with stepping away from the common pattern. I guess it should be written this way to make it clear that the pass is not a generic pass but rather a specific operation pass.

vzakhari: I see that many-many passes that are defined as `ModuleOp` passes in…

MogballUnsubmitted

Done

It is inconsistent throughout the MLIR codebase, but please return a Pass. There is no benefit to returning OperationPass<ModuleOp> because the pass manager API only accepts the former anyways.

Mogball: It is inconsistent throughout the MLIR codebase, but please return a `Pass`. There is no…

vzakhariAuthorUnsubmitted

Done

Will do.

vzakhari: Will do.

MogballUnsubmitted

Done

These functions normally don't take a PatternBenefit.

Mogball: These functions normally don't take a `PatternBenefit`.

vzakhariAuthorUnsubmitted

Done

There are some (e.g. ComplexToLLVM, MathToLibm), but it is currently not needed so I will remove it. It may be used in future in case there is target/project specific handling for such operations, e.g. in some cases there is target/project specific conversion for some flavors of the operation that is more preferable than MathToFuncs conversion - as I understand, in this case the patterns may be selected based on their benefit.

vzakhari: There are some (e.g. `ComplexToLLVM`, `MathToLibm`), but it is currently not needed so I will…

MogballUnsubmitted

Done

In that case, they wouldn't use these patterns or this pass. The validity of composing patterns is inconsistent.

Mogball: In that case, they wouldn't use these patterns or this pass. The validity of composing patterns…