[PATCH] D55467: [WebAssembly] Optimize Irreducible Control Flow
Heejin Ahn via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Dec 14 07:09:13 PST 2018
aheejin added a comment.
In the CL/commit description, could you add some explanation on what has changed, i.e., what unnecessary cases of transformation this patch reduces?
================
Comment at: lib/Target/WebAssembly/WebAssemblyFixIrreducibleControlFlow.cpp:85
AU.addRequired<MachineDominatorTree>();
AU.addPreserved<MachineDominatorTree>();
AU.addRequired<MachineLoopInfo>();
----------------
kripken wrote:
> aheejin wrote:
> > I don't think we need dominator tree anymore, so I think we can delete these two lines.
> You're right that we don't need it, but it turns out recomputing MLI crashes if I don't keep this code there. I guess the dominator tree is used in MLI, and MLI does not know to recompute it itself? (I don't know anything about LLVM internals...)
Oh, you're right, sorry.
================
Comment at: lib/Target/WebAssembly/WebAssemblyFixIrreducibleControlFlow.cpp:24
+/// then we have irreducible control flow. We fix that as follows: in each
+/// block reaching an entry we assign to a "label" helper variable with an id
+/// of the block we wish to reach, and branch to a new block that dispatches to
----------------
assign to -> assign?
================
Comment at: lib/Target/WebAssembly/WebAssemblyFixIrreducibleControlFlow.cpp:76
+ LoopFixer(MachineFunction &MF, MachineLoopInfo &MLI, MachineLoop *Loop) :
+ MF(MF), MLI(MLI), Loop(Loop) {}
+
----------------
clang-format
================
Comment at: lib/Target/WebAssembly/WebAssemblyFixIrreducibleControlFlow.cpp:98
+ // Get a canonical block to represent a block or a loop: the block, or if in
+ // a loop, the loop header, of it in an outer loop scope, we can ignore it.
+ MachineBasicBlock *canonicalize(MachineBasicBlock *MBB) {
----------------
a loop -> an inner loop, just to be clear
================
Comment at: lib/Target/WebAssembly/WebAssemblyFixIrreducibleControlFlow.cpp:183
+ }
}
----------------
Just a suggestion on the workflow... Currently `WorkList` is a class variable modified in multiple functions (inserted in `maybeInsert` and popped in `run`), and `maybeInsert` takes `MBB` and `Succ` but `MBB` is already canonicalized at that point but it canonicalize `Succ` within `maybeInsert` and if it is not canonicalized we bail out, which makes the workflow little hard to follow.
I think making `WorkList` as just a local variable within `run` and call both `canonicalize` and `canonicalizeSuccessor` in `run`, and inlining the remaining contents of `maybeInsert` into the `run` function would make it a bit simpler.
================
Comment at: lib/Target/WebAssembly/WebAssemblyFixIrreducibleControlFlow.cpp:222
+ SmallPtrSet<MachineBasicBlock *, 4> Entries;
+ SmallVector<MachineBasicBlock *, 4> SortedEntries;
+ for (auto *Looper : Loopers) {
----------------
Do we need two separate containers? If you want a vector with a O(1) search, maybe you can use `SetVector` and merge these two?
================
Comment at: lib/Target/WebAssembly/WebAssemblyFixIrreducibleControlFlow.cpp:235
+ // Check if we found irreducible control flow.
+ if (Entries.size() <= 1)
return false;
----------------
How about `if (LLVM_LIKELY(Entries.size() <= 1))` to signal we wouldn't find an irreducible control flow in usual cases?
================
Comment at: lib/Target/WebAssembly/WebAssemblyFixIrreducibleControlFlow.cpp:280
+
+ // Rewrite the problematic successors for every that wants to reach the bad
+ // blocks. For simplicity, we just introduce a new block for every edge we
----------------
Is there a word missing between 'every' and 'that'?
================
Comment at: lib/Target/WebAssembly/WebAssemblyFixIrreducibleControlFlow.cpp:397
+ // here.
+ while (runIteration(MF, MLI)) {
+ // We rewrote part of the function; recompute MLI and start again.
----------------
How about `while (LLVM_UNLIKELY(runIteration(MF, MLI))` to signal that this is unlikely to be true?
================
Comment at: test/CodeGen/WebAssembly/irreducible-cfg-exceptions.ll:4
+target datalayout = "e-m:e-p:32:32-i64:64-n32:64-S128"
+target triple = "wasm32-unknown-unknown-wasm"
+
----------------
Now we use just "wasm32-unknown-unknown". In other test cases too.
================
Comment at: test/CodeGen/WebAssembly/irreducible-cfg-exceptions.ll:6
+
+$crashy = comdat any
+
----------------
Can we delete this?
================
Comment at: test/CodeGen/WebAssembly/irreducible-cfg-exceptions.ll:17
+; Function Attrs: minsize noinline optsize
+define hidden void @crashy() unnamed_addr #0 comdat personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) {
+entry:
----------------
Can we delete all attributes (like #0, #1, ...) from this and other test cases if they are not necessary to show the bug? Also `hidden` and `unnamed_addr` can be deleted as well.
================
Comment at: test/CodeGen/WebAssembly/irreducible-cfg-exceptions.ll:113
+attributes #1 = { minsize optsize }
+attributes #2 = { minsize nounwind optsize }
+
----------------
We can delete these if not necessary (for other test cases too)
================
Comment at: test/CodeGen/WebAssembly/irreducible-cfg-nested.ll:11
+
+define dso_local fastcc void @tre_parse() unnamed_addr {
+entry:
----------------
I think we can delete `dso_local`, `fastcc`, and `unnamed_addr` here
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D55467/new/
https://reviews.llvm.org/D55467
More information about the llvm-commits
mailing list