This is an archive of the discontinued LLVM Phabricator instance.

[flang] Make `AbstractResultsOpt` run on `ModuleOp`
AbandonedPublic

Authored by unterumarmung on Jul 11 2022, 7:03 AM.

Details

Summary

This change introduce refactoring for the AbstractResultsOpt pass. Now this pass run on mlir::ModuleOp instead of mlir::func::FuncOp. this allows further changes to be made more easily - like converting "abstract results" in fir::GlobalOp.

  • mlir::func::FuncOp-related conversions were decoupled into FuncOpConversion
  • ReturnOpConversion was inlined to FuncOpConversion

Diff Detail

Event Timeline

unterumarmung created this revision.Jul 11 2022, 7:03 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald Transcript
unterumarmung requested review of this revision.Jul 11 2022, 7:03 AM

Added commit from D129485

Make the patch work & rebase

unterumarmung retitled this revision from WIP: [flang][NFC] Make `AbstractResultsOpt` run on `ModuleOp` to [flang][NFC] Make `AbstractResultsOpt` run on `ModuleOp`.Jul 12 2022, 8:19 AM
unterumarmung edited the summary of this revision. (Show Details)
unterumarmung added reviewers: clementval, schweitz.

Commit "[flang][NFC] Drop AbstractResultOptions structure" to be reviewed in D129485

unterumarmung retitled this revision from [flang][NFC] Make `AbstractResultsOpt` run on `ModuleOp` to [flang] Make `AbstractResultsOpt` run on `ModuleOp`.Jul 12 2022, 8:27 AM

Commit "[flang][NFC] Drop AbstractResultOptions structure" to be reviewed in D129485

You should make this patch dependent on D129485 so you do not have to include the change here. A patch should show a single commit.

flang/lib/Optimizer/Dialect/FIRType.cpp
940 ↗(On Diff #443954)

Commit "[flang][NFC] Drop AbstractResultOptions structure" to be reviewed in D129485

You should make this patch dependent on D129485 so you do not have to include the change here. A patch should show a single commit.

Done, thank you!

In fact I think it will be better to keep the pass running on function so we can keep the multithreading from MLIR. Then for the GlobalOp we can just have a separate conversion pattern that reuse the code from here.

In fact I think it will be better to keep the pass running on function so we can keep the multithreading from MLIR. Then for the GlobalOp we can just have a separate conversion pattern that reuse the code from here.

I didn't quite get how you want to reuse the conversion, but I can propose the following "architecture":

template <typename Op>
class AbstractResultBase { ... };

contains common logic of both FuncOp and GlobalOp

class AbstractResultInFuncOpt : AbstractResultBase<FuncOp>, /* Base from TableGen-generated code */ { ... };

contains rewriting of signature and adding ReturnOp conversion pattern to the mlir::RewritePatternSet patterns

class AbstractResultInGlobalOpt : AbstractResultBase<GlobalOp>, /* Base from TableGen-generated code */ { ... };

probably will be empty. Or is there some GlobalOp-specific quirks that have to be handled?

unterumarmung abandoned this revision.Aug 1 2022, 5:14 AM