-
Notifications
You must be signed in to change notification settings - Fork 201
Branch comparison folding and order optimizations #629
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like this is on the right track!
Long term, I think this is additional motivation for Cranelift developing more convenient APIs for pattern-matching, as it's a fair amount of work to dig out all the required bits and test all the needed conditions manually like this :-).
c8cc35e
to
2b129f3
Compare
Cargo.toml
Outdated
@@ -14,7 +14,7 @@ name = "clif-util" | |||
path = "src/clif-util.rs" | |||
|
|||
[dependencies] | |||
cfg-if = "0.1" | |||
cfg-if = "0.1.6" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This appears to have been underspecified. With v0.1.4 locally, I was getting errors about missing macros. Presumably due to lack of this commit: rust-lang/cfg-if@67e01e5
I think this is ready for another round of reviews. |
2b129f3
to
6d5ff80
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, overall this looks good!
Hi @tyler ! Any idea when/if you'd have time to address the review comments and rebase this PR here? Or can we help you moving this forward by taking over the remaining changes? |
hey @bnjbvr, yeah I can get back to this soon. I'll try to get to that this afternoon. |
(If I don't, feel free to take it over. :)) |
… into 'brz' or 'brnz'.
…ends actually produce.
…ntends should produce.
6d5ff80
to
b26d781
Compare
@sunfishcode or @bnjbvr, do you want to take another look before merge? I think I addressed all the things. |
Thanks @tyler! I'll try to take a look at this early next week. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, thanks for doing this and adding tests! I've got a few suggestions which could make the code easier to follow, let me know if they make sense to you.
I believe you meant |
Surprisingly, I didn't. I was referring to re-ordering branches. :) |
Thanks, looks great! |
…f1; r=lth The one optimization introduced by this is the rearrangement of branches to prefer fallthrough whenever possible, as well as folding branches when comparing against 0. See also bytecodealliance/cranelift#629 for details. Differential Revision: https://phabricator.services.mozilla.com/D28512 --HG-- extra : rebase_source : f0d765a1cb1e2f7872037c18b9951077a08ae4b7 extra : histedit_source : 1a1dd95618e166705f7165c045f3b5af12f96d5b
…f1; r=lth The one optimization introduced by this is the rearrangement of branches to prefer fallthrough whenever possible, as well as folding branches when comparing against 0. See also bytecodealliance/cranelift#629 for details. Differential Revision: https://phabricator.services.mozilla.com/D28512 --HG-- extra : moz-landing-system : lando
…f1; r=lth The one optimization introduced by this is the rearrangement of branches to prefer fallthrough whenever possible, as well as folding branches when comparing against 0. See also bytecodealliance/cranelift#629 for details. Differential Revision: https://phabricator.services.mozilla.com/D28512
…f1; r=lth The one optimization introduced by this is the rearrangement of branches to prefer fallthrough whenever possible, as well as folding branches when comparing against 0. See also bytecodealliance/cranelift#629 for details. Differential Revision: https://phabricator.services.mozilla.com/D28512
…f1; r=lth The one optimization introduced by this is the rearrangement of branches to prefer fallthrough whenever possible, as well as folding branches when comparing against 0. See also bytecodealliance/cranelift#629 for details. Differential Revision: https://phabricator.services.mozilla.com/D28512 UltraBlame original commit: 5acf68edbf599cafcf131d5fa2eb5e70c67279b8
…f1; r=lth The one optimization introduced by this is the rearrangement of branches to prefer fallthrough whenever possible, as well as folding branches when comparing against 0. See also bytecodealliance/cranelift#629 for details. Differential Revision: https://phabricator.services.mozilla.com/D28512 UltraBlame original commit: 5acf68edbf599cafcf131d5fa2eb5e70c67279b8
…f1; r=lth The one optimization introduced by this is the rearrangement of branches to prefer fallthrough whenever possible, as well as folding branches when comparing against 0. See also bytecodealliance/cranelift#629 for details. Differential Revision: https://phabricator.services.mozilla.com/D28512 UltraBlame original commit: 5acf68edbf599cafcf131d5fa2eb5e70c67279b8
Fixes #606.
This PR add two optimizations to
simple_preopt.rs
. The first is to fold code where we compare against zero, then use an explicit conditional branch. For instance:becomes
For x86-64 this doesn't actually make much difference, as it compiles to a
test
rather than acmp
, which should be very near equivalent. But it does save a byte on a very common operation, so hey.The second is reordering branches at the end of ebbs to encourage fallthroughs. As pointed out in #606, it's common for wasm code to be compiled like this:
Which ends up being compiled as a conditional jump followed by a jump. However, we can switch those instructions by flipping the destinations and inverting the conditional jump's condition, like so:
And when we do that we eliminate the latter jump entirely.