delta/llvm.git/mlir/lib/Transforms/Inliner.cpp, branch EmptyLineAfterFunctionDefinition github.com: llvm/llvm-project.git Remove unused llvm/Support/Parallel.h from MLIR (NFC) 2021-09-14T23:30:42+00:00 Mehdi Amini joker.eph@gmail.com 2021-09-14T23:30:42+00:00 1a406cd5f2e2403b325f6d914b692459a2ab3b9b This header aren't needed anymore: MLIR is using a thread pool injected in the context instead of a global one. 
This header aren't needed anymore: MLIR is using a thread pool
injected in the context instead of a global one.
[mlir] Add missing namespace to createInlinerPass 2021-09-13T09:58:27+00:00 Valentin Clement clementval@gmail.com 2021-09-13T09:58:07+00:00 57bf85601168ba4bf2798455b4bfea674c9f92d3 One of the createInlinerPass does not have the mlir:: namespace Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D109580 
One of the createInlinerPass does not have the mlir:: namespace

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D109580
[mlir] Add a ThreadPool to MLIRContext and refactor MLIR threading usage 2021-06-23T01:29:24+00:00 River Riddle riddleriver@gmail.com 2021-06-23T01:16:55+00:00 6569cf2a44bf95106e7168bdb79c4674742708fa This revision refactors the usage of multithreaded utilities in MLIR to use a common thread pool within the MLIR context, in addition to a new utility that makes writing multi-threaded code in MLIR less error prone. Using a unified thread pool brings about several advantages: * Better thread usage and more control We currently use the static llvm threading utilities, which do not allow multiple levels of asynchronous scheduling (even if there are open threads). This is due to how the current TaskGroup structure works, which only allows one truly multithreaded instance at a time. By having our own ThreadPool we gain more control and flexibility over our job/thread scheduling, and in a followup can enable threading more parts of the compiler. * The static nature of TaskGroup causes issues in certain configurations Due to the static nature of TaskGroup, there have been quite a few problems related to destruction that have caused several downstream projects to disable threading. See D104207 for discussion on some related fallout. By having a ThreadPool scoped to the context, we don't have to worry about destruction and can ensure that any additional MLIR thread usage ends when the context is destroyed. Differential Revision: https://reviews.llvm.org/D104516 
This revision refactors the usage of multithreaded utilities in MLIR to use a common
thread pool within the MLIR context, in addition to a new utility that makes writing
multi-threaded code in MLIR less error prone. Using a unified thread pool brings about
several advantages:

* Better thread usage and more control
We currently use the static llvm threading utilities, which do not allow multiple
levels of asynchronous scheduling (even if there are open threads). This is due to
how the current TaskGroup structure works, which only allows one truly multithreaded
instance at a time. By having our own ThreadPool we gain more control and flexibility
over our job/thread scheduling, and in a followup can enable threading more parts of
the compiler.

* The static nature of TaskGroup causes issues in certain configurations
Due to the static nature of TaskGroup, there have been quite a few problems related to
destruction that have caused several downstream projects to disable threading. See
D104207 for discussion on some related fallout. By having a ThreadPool scoped to
the context, we don't have to worry about destruction and can ensure that any
additional MLIR thread usage ends when the context is destroyed.

Differential Revision: https://reviews.llvm.org/D104516
[mlir][Inliner] Don't optimize callees in async mode if there is only one to optimize 2021-02-24T02:44:09+00:00 River Riddle riddleriver@gmail.com 2021-02-24T02:43:55+00:00 59f0e4627a5e8789c9ab997cd13f96600848fea8 This avoids unnecessary async overhead in situations that won't benefit from it. 
This avoids unnecessary async overhead in situations that won't benefit from it.
[mlir][Inliner] Keep the number of async pass managers constant 2021-02-24T00:40:24+00:00 River Riddle riddleriver@gmail.com 2021-02-24T00:40:09+00:00 16a50c9e642fd085e5ceb68c403b71b5b2e0607c This prevents a bug in the pass instrumentation implementation where the main thread would end up with a different pass manager in different runs of the pass. 
This prevents a bug in the pass instrumentation implementation where the main thread would end up with a different pass manager in different runs of the pass.
[mlir][Inliner] Use llvm::parallelForEach instead of llvm::parallelTransformReduce 2021-02-23T22:36:45+00:00 River Riddle riddleriver@gmail.com 2021-02-23T22:22:30+00:00 abd3c6f24c823be6fb316b501482d8637c4a0724 llvm::parallelTransformReduce does not schedule work on the caller thread, which becomes very costly for the inliner where a majority of SCCs are small, often ~1 element. The switch to llvm::parallelForEach solves this, and also aligns the implementation with the PassManager (which realistically should share the same implementation). This change dropped compile time on an internal benchmark by ~1(25%) second. Differential Revision: https://reviews.llvm.org/D96086 
llvm::parallelTransformReduce does not schedule work on the caller thread, which becomes very costly for
the inliner where a majority of SCCs are small, often ~1 element. The switch to llvm::parallelForEach solves this,
and also aligns the implementation with the PassManager (which realistically should share the same implementation).

This change dropped compile time on an internal benchmark by ~1(25%) second.

Differential Revision: https://reviews.llvm.org/D96086
[mlir][IR] Remove the concept of `OperationProperties` 2021-02-09T20:00:15+00:00 River Riddle riddleriver@gmail.com 2021-02-09T19:41:10+00:00 fe7c0d90b2940232cc6ab396253091bcf1ca4f2f These properties were useful for a few things before traits had a better integration story, but don't really carry their weight well these days. Most of these properties are already checked via traits in most of the code. It is better to align the system around traits, and improve the performance/cost of traits in general. Differential Revision: https://reviews.llvm.org/D96088 
These properties were useful for a few things before traits had a better integration story, but don't really carry their weight well these days. Most of these properties are already checked via traits in most of the code. It is better to align the system around traits, and improve the performance/cost of traits in general.

Differential Revision: https://reviews.llvm.org/D96088
[mlir] Mark LogicalResult as LLVM_NODISCARD 2021-02-04T23:10:10+00:00 River Riddle riddleriver@gmail.com 2021-02-04T22:57:50+00:00 e21adfa32d8822f9ea4058c3e365a841d87cb3ee This makes ignoring a result explicit by the user, and helps to prevent accidental errors with dropped results. Marking LogicalResult as no discard was always the intention from the beginning, but got lost along the way. Differential Revision: https://reviews.llvm.org/D95841 
This makes ignoring a result explicit by the user, and helps to prevent accidental errors with dropped results. Marking LogicalResult as no discard was always the intention from the beginning, but got lost along the way.

Differential Revision: https://reviews.llvm.org/D95841
[mlir] Skip empty op-pipelines in inliner textual opt parsing 2020-12-29T21:59:53+00:00 Jacques Pienaar jpienaar@google.com 2020-12-29T21:59:53+00:00 e03266994af898efcde7b27936250e85f774f39f Avoids failing on cases like inline{default-pipeline=canonicalize max-iterations=4 op-pipelines=}, as produced by crash reproducer. 
Avoids failing on cases like

inline{default-pipeline=canonicalize max-iterations=4 op-pipelines=},

as produced by crash reproducer.
[mlir][Inliner] Refactor the inliner to use nested pass pipelines instead of just canonicalization 2020-12-15T02:09:47+00:00 River Riddle riddleriver@gmail.com 2020-12-15T02:07:45+00:00 d7eba2005267aa4a8f46f73f208c7cc23e6c6a1a Now that passes have support for running nested pipelines, the inliner can now allow for users to provide proper nested pipelines to use for optimization during inlining. This revision also changes the behavior of optimization during inlining to optimize before attempting to inline, which should lead to a more accurate cost model and prevents the need for users to schedule additional duplicate cleanup passes before/after the inliner that would already be run during inlining. Differential Revision: https://reviews.llvm.org/D91211 
Now that passes have support for running nested pipelines, the inliner can now allow for users to provide proper nested pipelines to use for optimization during inlining. This revision also changes the behavior of optimization during inlining to optimize before attempting to inline, which should lead to a more accurate cost model and prevents the need for users to schedule additional duplicate cleanup passes before/after the inliner that would already be run during inlining.

Differential Revision: https://reviews.llvm.org/D91211