- User Since
- Oct 16 2019, 1:22 AM (49 w, 1 d)
Jul 20 2020
I just wonder if there is anyone counting on the current ordering of uses.
Although, I think they shouldn't...
I like it! Great job!
Jun 26 2020
Jun 25 2020
I admit, I don't like this change. This is a work around a design flaw in the old PM. However, it seems like the right decision to handle it, right now.
I think we should post a RFC for a new - *cough* - PM... ;)
Jun 24 2020
Jun 18 2020
This change should be split into 2.
One for the PM changes and the other for the LoopExtractor (that depend on the previous change).
Regardless, the changes in the PM should be reviewed by more people...
Jun 10 2020
This makes more sense. Every pass (in our case - BreakCriticalEdges) is responsible for reporting to the PM about the preserved (and non preserved) analyses.
I am not sure, what bug are you trying to tackle?
In case the LoopExtractor does nothing, it will report that all analyses are preserved, but the preceding call to BreakCriticalEdges will (and if it doesn't - it should) already report the non preserved analyses.
I guess, what you didn't expect is the fact that running the LoopExtractor will trigger BreakCriticalEdges, but although it may be a strange/ugly behavior, it is still valid.
Jun 5 2020
There seems to be a more profound bug underneath.
Is this how every pass that use LoopInfo handle it?
It seems like the real issue is with LoopInfo - an analysis shouldn't do a transformation.
Jun 1 2020
May 30 2020
Update algorithm to use a custom GraphTraits and a NodeRef that holds the set of nodes for the subgraph.
This simplifies the algorithm quite a bit.
May 29 2020
May 28 2020
May 27 2020
Added a test case.
May 26 2020
Updated tests to fit the change.
This is a second take of the solution, using SCCs instead of LoopInfo.
This algorithm can also handle irreducible loops, and, generally, any kind of cycle in the graph.
May 24 2020
May 21 2020
Of course, this requires also fixing the tests affected by this change; but I wanted to present the change first, and if approved, I'll work on fixing the tests.
We need to move up the check for *CurrentLoopSize, as in the case it is zero, then we no longer need to skip nodes, and just continue to the next node/loop.
The simplified, new test case, demonstrate a case where it is needed.
Simplified the new test case.
May 20 2020
May 14 2020
Fixed the bug causing an infinite loop in the new testcase.
Thanks both of you.
I'll revert and update the patch for it.
Waiting for a test case...
May 13 2020
May 12 2020
Rename Invert2 variable to InvertCond2.
Hope it makes more sense.
May 11 2020
May 10 2020
Added test for interleaved sibling loops, and change the test file name to "interleaved-loop-order.ll".
May 7 2020
May 6 2020
I don't think it is possible, although I might be wrong.
Because the way I see it, for loop A be interfered with another loop B, while POT, there must be at least one block that belongs to loop A that is dependent on at least one block in loop B. But then loop B must be finished before loop A, and actually inside it. Otherwise, it won't be recognized as a separate loop.
The problem with those tests is something else, and not produced by the wrong ordering. You may refer to PR25378 for an example.
Still, this fix the ordering issue and fixes PR41509 (and its duplicates).
I think we should insert this patch, and attend to the other bug as a separate issue.
May 4 2020
May 3 2020
Done requested changes.
May 2 2020
I am not sure what do you mean. In this page in the Phabricator, under [Revision Contents]->[History] you can choose which of the patch revisions to diff. The default is "Base" against the latest "Diff no.".
May 1 2020
Thanks for the references.
I'm abandoning this change, due to lack of interest.
Apr 30 2020
Done requested changes.
Apr 29 2020
Apr 28 2020
Apr 26 2020
Apr 25 2020
Apr 24 2020
Update test to include debug info, and add some comments.
Apr 23 2020
Apr 16 2020
Apr 15 2020
Changed the name of the test file to pr45476.cpp.
Simplify function using IgnoreParenNoopCasts.
Apr 14 2020
Use the old structure of the algorithm, with the fix, as requested.
Apr 12 2020
The variables naming convention is inconsistent.
LLVM is using CamelCase while MLIR is using camelBack.
I know there have been some discussions regarding changing LLVM to use camelBack for variables as well, but I am not sure if there was any conclusion...
Apr 11 2020
Note that MLIR_MAIN_INCLUDE_DIR is used in almost all (if not all) the CMakeLists.txt in the project.
Apr 3 2020
"llvm/docs/ProgrammersManual.rst" needs to be updated as well.
Apr 1 2020
Let me shed a little light on the Waymarking algorithm: