[Bug middle-end/95922] Failure to optimize `((b ^ a) & c) ^ a` to `(a & ~c) | (b & c)` the right way on architectures with andnot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95922 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- Dup of bug 94790. *** This bug has been marked as a duplicate of bug 94790 ***
[Bug middle-end/95922] Failure to optimize `((b ^ a) & c) ^ a` to `(a & ~c) | (b & c)` the right way on architectures with andnot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95922 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug middle-end/95922] Failure to optimize `((b ^ a) & c) ^ a` to `(a & ~c) | (b & c)` the right way on architectures with andnot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95922 --- Comment #3 from Gabriel Ravier --- Hm, I guess with the andn it avoids a move, though that isn't much. I posted this here months ago actually, so idk really what I was thinking... I guess it might help in some further transformations, but it seems bad overall yeah.
[Bug middle-end/95922] Failure to optimize `((b ^ a) & c) ^ a` to `(a & ~c) | (b & c)` the right way on architectures with andnot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95922 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- What would be the advantage of doing that? Same number of instructions, but with andn 3 bytes longer...
[Bug middle-end/95922] Failure to optimize `((b ^ a) & c) ^ a` to `(a & ~c) | (b & c)` the right way on architectures with andnot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95922 Richard Biener changed: What|Removed |Added Component|tree-optimization |middle-end --- Comment #1 from Richard Biener --- Should be expand-time optimization since on GIMPLE it takes one more instruction.
