You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was looking at what's essentially <= on a 4-tuple in Rust, and ended up with the following IR: https://llvm.godbolt.org/z/8zaYxd8qM (That link includes that trunk opt doesn't change it.)
That 2 came from Option<bool>::None in Rust, but it would be really nice if LLVM could notice that it being specifically 2 is not something that makes it to the output at all, and thus it could be changed to something more convenient for the logic.
Specifically, in this case the other two phi inputs are just zexted icmps, and the function is returning i1, so if it's changed to 1 then everything else in that block can be greatly simplified:
I was looking at what's essentially
<=
on a 4-tuple in Rust, and ended up with the following IR: https://llvm.godbolt.org/z/8zaYxd8qM (That link includes that trunkopt
doesn't change it.)Full IR so there's a non-godbolt copy
The part I want to draw attention to specifically is the end:
That
2
came fromOption<bool>::None
in Rust, but it would be really nice if LLVM could notice that it being specifically 2 is not something that makes it to the output at all, and thus it could be changed to something more convenient for the logic.Specifically, in this case the other two phi inputs are just
zext
edicmp
s, and the function is returningi1
, so if it's changed to1
then everything else in that block can be greatly simplified:That way there's no need for the
eq
+or
, and thetrunc
becomesnuw
which could collapse into the phi and the predecessors too.The text was updated successfully, but these errors were encountered: