<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/mlir/test/lib/Analysis/TestSlice.cpp, branch main</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/'/>
<entry>
<title>[MLIR][Analysis] Consolidate topological sort utilities  (#92563)</title>
<updated>2024-05-22T06:48:10+00:00</updated>
<author>
<name>Christian Ulmann</name>
<email>christianulmann@gmail.com</email>
</author>
<published>2024-05-22T06:48:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=b00e0c167186d69e1e6bceda57c09b272bd6acfc'/>
<id>b00e0c167186d69e1e6bceda57c09b272bd6acfc</id>
<content type='text'>
This PR attempts to consolidate the different topological sort utilities
into one place. It adds them to the analysis folder because the
`SliceAnalysis` uses some of these.

There are now two different sorting strategies: 
1. Sort only according to SSA use-def chains
2. Sort while taking regions into account. This requires a much more
elaborate traversal and cannot be applied on graph regions that easily.

This additionally reimplements the region aware topological sorting
because the previous implementation had an exponential space complexity.

I'm open to suggestions on how to combine this further or how to fuse
the test passes.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This PR attempts to consolidate the different topological sort utilities
into one place. It adds them to the analysis folder because the
`SliceAnalysis` uses some of these.

There are now two different sorting strategies: 
1. Sort only according to SSA use-def chains
2. Sort while taking regions into account. This requires a much more
elaborate traversal and cannot be applied on graph regions that easily.

This additionally reimplements the region aware topological sorting
because the previous implementation had an exponential space complexity.

I'm open to suggestions on how to combine this further or how to fuse
the test passes.</pre>
</div>
</content>
</entry>
<entry>
<title>[mlir][NFC] Drop a few unnecessary includes from Pass.h</title>
<updated>2022-04-08T06:42:47+00:00</updated>
<author>
<name>River Riddle</name>
<email>riddleriver@gmail.com</email>
</author>
<published>2022-04-08T06:29:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=36d3efea15e6202edd64b05de38d8379e2baddb2'/>
<id>36d3efea15e6202edd64b05de38d8379e2baddb2</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[mlir] Rework the implementation of TypeID</title>
<updated>2022-04-04T20:52:26+00:00</updated>
<author>
<name>River Riddle</name>
<email>riddleriver@gmail.com</email>
</author>
<published>2022-03-31T00:00:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=5e50dd048e3a20cde5da5d7a754dfee775ef35d6'/>
<id>5e50dd048e3a20cde5da5d7a754dfee775ef35d6</id>
<content type='text'>
This commit restructures how TypeID is implemented to ideally avoid
the current problems related to shared libraries. This is done by changing
the "implicit" fallback path to use the name of the type, instead of using
a static template variable (which breaks shared libraries). The major downside to this
is that it adds some additional initialization costs for the implicit path. Given the
use of type names for uniqueness in the fallback, we also no longer allow types
defined in anonymous namespaces to have an implicit TypeID. To simplify defining
an ID for these classes, a new `MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID` macro
was added to allow for explicitly defining a TypeID directly on an internal class.

To help identify when types are using the fallback, `-debug-only=typeid` can be
used to log which types are using implicit ids.

This change generally only requires changes to the test passes, which are all defined
in anonymous namespaces, and thus can't use the fallback any longer.

Differential Revision: https://reviews.llvm.org/D122775
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This commit restructures how TypeID is implemented to ideally avoid
the current problems related to shared libraries. This is done by changing
the "implicit" fallback path to use the name of the type, instead of using
a static template variable (which breaks shared libraries). The major downside to this
is that it adds some additional initialization costs for the implicit path. Given the
use of type names for uniqueness in the fallback, we also no longer allow types
defined in anonymous namespaces to have an implicit TypeID. To simplify defining
an ID for these classes, a new `MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID` macro
was added to allow for explicitly defining a TypeID directly on an internal class.

To help identify when types are using the fallback, `-debug-only=typeid` can be
used to log which types are using implicit ids.

This change generally only requires changes to the test passes, which are all defined
in anonymous namespaces, and thus can't use the fallback any longer.

Differential Revision: https://reviews.llvm.org/D122775
</pre>
</div>
</content>
</entry>
<entry>
<title>[mlir][test] Generalize a bunch of FuncOp based passes to run on any operation/interfaces</title>
<updated>2022-03-08T20:25:32+00:00</updated>
<author>
<name>River Riddle</name>
<email>riddleriver@gmail.com</email>
</author>
<published>2022-03-08T02:19:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=87d6bf37288d47ddf702ac4da2cb61006feadbab'/>
<id>87d6bf37288d47ddf702ac4da2cb61006feadbab</id>
<content type='text'>
A lot of test passes are currently anchored on FuncOp, but this
dependency
is generally just historical. A majority of these test passes can run on
any operation, or can operate on a specific interface
(FunctionOpInterface/SymbolOpInterface).
This allows for greatly reducing the API dependency on FuncOp, which
is slated to be moved out of the Builtin dialect.

Differential Revision: https://reviews.llvm.org/D121191
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A lot of test passes are currently anchored on FuncOp, but this
dependency
is generally just historical. A majority of these test passes can run on
any operation, or can operate on a specific interface
(FunctionOpInterface/SymbolOpInterface).
This allows for greatly reducing the API dependency on FuncOp, which
is slated to be moved out of the Builtin dialect.

Differential Revision: https://reviews.llvm.org/D121191
</pre>
</div>
</content>
</entry>
<entry>
<title>[mlir][Pass] Deprecate FunctionPass in favor of OperationPass&lt;FuncOp&gt;</title>
<updated>2022-01-19T03:52:44+00:00</updated>
<author>
<name>River Riddle</name>
<email>riddleriver@gmail.com</email>
</author>
<published>2022-01-04T23:41:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=41574554257b4ebb478b89c01497a05773dbfc14'/>
<id>41574554257b4ebb478b89c01497a05773dbfc14</id>
<content type='text'>
The only benefit of FunctionPass is that it filters out function
declarations. This isn't enough to justify carrying it around, as we can
simplify filter out declarations when necessary within the pass. We can
also explore with better scheduling primitives to filter out declarations
at the pipeline level in the future.

The definition of FunctionPass is left intact for now to allow time for downstream
users to migrate.

Differential Revision: https://reviews.llvm.org/D117182
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The only benefit of FunctionPass is that it filters out function
declarations. This isn't enough to justify carrying it around, as we can
simplify filter out declarations when necessary within the pass. We can
also explore with better scheduling primitives to filter out declarations
at the pipeline level in the future.

The definition of FunctionPass is left intact for now to allow time for downstream
users to migrate.

Differential Revision: https://reviews.llvm.org/D117182
</pre>
</div>
</content>
</entry>
<entry>
<title>Adjust "end namespace" comment in MLIR to match new agree'd coding style</title>
<updated>2021-12-08T06:05:26+00:00</updated>
<author>
<name>Mehdi Amini</name>
<email>joker.eph@gmail.com</email>
</author>
<published>2021-12-07T18:27:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=be0a7e9f27083ada6072fcc0711ffa5630daa5ec'/>
<id>be0a7e9f27083ada6072fcc0711ffa5630daa5ec</id>
<content type='text'>
See D115115 and this mailing list discussion:
https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.html

Differential Revision: https://reviews.llvm.org/D115309
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
See D115115 and this mailing list discussion:
https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.html

Differential Revision: https://reviews.llvm.org/D115309
</pre>
</div>
</content>
</entry>
<entry>
<title>[mlir] Make topologicalSort iterative and consider op regions</title>
<updated>2021-11-10T18:05:01+00:00</updated>
<author>
<name>thomasraoux</name>
<email>thomasraoux@google.com</email>
</author>
<published>2021-11-10T02:11:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=5aa6038a407451da2ca5438c5b03c40aa4c72aad'/>
<id>5aa6038a407451da2ca5438c5b03c40aa4c72aad</id>
<content type='text'>
When doing topological sort we need to make sure an op is scheduled before any
of the ops within its regions.
Also change the algorithm to not be recursive in order to prevent potential
stack overflow.

Differential Revision: https://reviews.llvm.org/D113423
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When doing topological sort we need to make sure an op is scheduled before any
of the ops within its regions.
Also change the algorithm to not be recursive in order to prevent potential
stack overflow.

Differential Revision: https://reviews.llvm.org/D113423
</pre>
</div>
</content>
</entry>
</feed>
