egraphs: Recognize bitselect from bitwise operations#6879
egraphs: Recognize bitselect from bitwise operations#6879afonso360 merged 2 commits intobytecodealliance:mainfrom
bitselect from bitwise operations#6879Conversation
github-actions
bot
added
cranelift
Subscribe to Label ActionDetailsThis issue or pull request has been labeled: "cranelift", "isle"Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
fitzgen
left a comment
fitzgen
left a comment
There was a problem hiding this comment.
LGTM, but can we please add some runtests as well? Thanks!
A bit of an aside, but it also makes me think that we should make the runtest runner automatically run tests twice, once with optimizations and once without them. Because we want that for every single runtest that exercises any mid-end rewrite rule, and it definitely doesn't hurt for runtests that are just stressing lowering or something.
|
Looks like the x86 backend does not have scalar bitselect implemented. I'm going to try to work on that so that we don't an optimization that generates code that can't be lowered. |
afonso360
force-pushed
the
opt-bitselect
branch
from
f0b3594 to
72f3683
Compare
|
I've restricted this transform for vectors only since each backend implements a different subset of |
afonso360
force-pushed
the
opt-bitselect
branch
from
72f3683 to
3e9e43e
Compare
jameysharp
left a comment
jameysharp
left a comment
There was a problem hiding this comment.
That's a good restriction to adopt for now and a good assortment of new tests. Thanks!
…nce#6879) * egraphs: Transform bitops into a `bitselect` * cranelift: Add bitwise bitselect tests
3 participants
👋 Hey,
While working on #6876, I noticed we don't yet recognize this pattern for bitselects. I've also added the various permutations of this rule since I don't think we rotate inputs on bitwise operations. (And my understanding is that we shouldn't do so)