9 Commits

Author SHA1 Message Date
Maksim Levental
46f6df0848
[mlir][NFC] update flang/Optimizer/Transforms create APIs (11/n) (#149915)
See https://github.com/llvm/llvm-project/pull/147168 for more info.
2025-07-21 19:37:17 -04:00
Oleksandr "Alex" Zinenko
0c61b24337
[mlir] add a fluent API to GreedyRewriterConfig (#137122)
This is similar to other configuration objects used across MLIR.

Rename some fields to better reflect that they are no longer booleans.

Reland 04d261101b4f229189463136a794e3e362a793af / #132253.
2025-04-24 09:51:42 +02:00
Kazu Hirata
4cb9a3700c Revert "[mlir] add a fluent API to GreedyRewriterConfig (#132253)"
This reverts commit 63b8f1c9482ed0a964980df4aed89bef922b8078.

Buildbot failure:
https://lab.llvm.org/buildbot/#/builders/172/builds/12083/steps/5/logs/stdio

I've reproduced the error with a release build (-DCMAKE_BUILD_TYPE=Release).
2025-04-18 09:40:28 -07:00
Oleksandr "Alex" Zinenko
63b8f1c948
[mlir] add a fluent API to GreedyRewriterConfig (#132253)
This is similar to other configuration objects used across MLIR.
2025-04-18 15:19:57 +02:00
Jacques Pienaar
09dfc5713d
[mlir] Enable decoupling two kinds of greedy behavior. (#104649)
The greedy rewriter is used in many different flows and it has a lot of
convenience (work list management, debugging actions, tracing, etc). But
it combines two kinds of greedy behavior 1) how ops are matched, 2)
folding wherever it can.

These are independent forms of greedy and leads to inefficiency. E.g.,
cases where one need to create different phases in lowering and is
required to applying patterns in specific order split across different
passes. Using the driver one ends up needlessly retrying folding/having
multiple rounds of folding attempts, where one final run would have
sufficed.

Of course folks can locally avoid this behavior by just building their
own, but this is also a common requested feature that folks keep on
working around locally in suboptimal ways.

For downstream users, there should be no behavioral change. Updating
from the deprecated should just be a find and replace (e.g., `find ./
-type f -exec sed -i
's|applyPatternsAndFoldGreedily|applyPatternsGreedily|g' {} \;` variety)
as the API arguments hasn't changed between the two.
2024-12-20 08:15:48 -08:00
jeanPerier
2051a7bcd3
[flang][NFC] turn fir.call is_bind_c into enum for procedure flags (#105691)
First patch to fix a BIND(C) ABI issue
(https://github.com/llvm/llvm-project/issues/102113). I need to keep
track of BIND(C) in more locations (fir.dispatch and func.func
operations), and I need to fix a few passes that are dropping the
attribute on the floor. Since I expect more procedure attributes that
cannot be reflected in mlir::FunctionType will be needed for ABI,
optimizations, or debug info, this NFC patch adds a new enum attribute
to keep track of procedure attributes in the IR.

This patch is not updating lowering to lower more attributes, this will
be done in a separate patch to keep the test changes low here.

Adding the attribute on fir.dispatch and func.func will also be done in
separate patches.
2024-08-23 14:32:43 +02:00
Kazu Hirata
8470cdd499
[flang] Use llvm::any_of and llvm::none_of (NFC) (#102797) 2024-08-12 10:24:18 -07:00
Ramkumar Ramachandra
db791b278a
mlir/LogicalResult: move into llvm (#97309)
This patch is part of a project to move the Presburger library into
LLVM.
2024-07-02 10:42:33 +01:00
Mats Petersson
de528ffb17
[Flang] Extracting internal constants from scalar literals (#73829)
Constants actual arguments in function/subroutine calls are currently
lowered as allocas + store. This can sometimes inhibit LTO and the
constant will not be propagated to the called function. Particularly in
cases where the function/subroutine call happens inside a condition.

This patch changes the lowering of these constant actual arguments to a
global constant + fir.address_of_op. This lowering makes it easier for
LTO to propagate the constant.

The optimization must be enabled explicitly to run. Use -mmlir
--enable-constant-argument-globalisation to enable.

---------

Co-authored-by: Dmitriy Smirnov <dmitriy.smirnov@arm.com>
2024-06-25 15:42:02 +01:00