[Bug middle-end/66588] combine should try transforming if_then_else of zero_extends into zero_extend of if_then_else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66588 --- Comment #8 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:04a9209dc865dafe3c9615f5c868aa3fd89b96cf commit r14-89-g04a9209dc865dafe3c9615f5c868aa3fd89b96cf Author: Andrew Pinski Date: Thu Apr 13 00:40:40 2023 + i386: Add new pattern for zero-extend cmov After a phiopt change, I got a failure of cmov9.c. The RTL IR has zero_extend on the outside of the if_then_else rather than on the side. Both ways are considered canonical as mentioned in PR 66588. This fixes the failure I got and also adds a testcase which fails before even my phiopt patch but will pass with this patch. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. gcc/ChangeLog: * config/i386/i386.md (*movsicc_noc_zext_1): New pattern. gcc/testsuite/ChangeLog: * gcc.target/i386/cmov10.c: New test. * gcc.target/i386/cmov11.c: New test.
[Bug middle-end/66588] combine should try transforming if_then_else of zero_extends into zero_extend of if_then_else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66588 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #7 from Segher Boessenkool --- .
[Bug middle-end/66588] combine should try transforming if_then_else of zero_extends into zero_extend of if_then_else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66588 --- Comment #6 from Segher Boessenkool --- Yeah let's close this. Thanks.
[Bug middle-end/66588] combine should try transforming if_then_else of zero_extends into zero_extend of if_then_else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66588 --- Comment #5 from ktkachov at gcc dot gnu.org --- (In reply to Segher Boessenkool from comment #4) combine should not in general try multiple ways to write the same thing; this will not scale. In this case, I don't see that some backends would really like to write it one way and some the other, so we should just use one way. There are no defined canonicalization rules for this, but there are for the similar cases involving MULT, where the extends are moved inwards as well. This is most in line with how other extends are treated as well. We probably should document the canonicalization rules better; current practice for backends is to just look at what combine does and use that; not a great idea in my opinion. Ok, thanks. I've opened PR 66776 for the aarch64 MD changes. Would you like to keep this open to track any documentation changes? Or shall we close this off?
[Bug middle-end/66588] combine should try transforming if_then_else of zero_extends into zero_extend of if_then_else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66588 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #4 from Segher Boessenkool segher at gcc dot gnu.org --- combine should not in general try multiple ways to write the same thing; this will not scale. In this case, I don't see that some backends would really like to write it one way and some the other, so we should just use one way. There are no defined canonicalization rules for this, but there are for the similar cases involving MULT, where the extends are moved inwards as well. This is most in line with how other extends are treated as well. We probably should document the canonicalization rules better; current practice for backends is to just look at what combine does and use that; not a great idea in my opinion.
[Bug middle-end/66588] combine should try transforming if_then_else of zero_extends into zero_extend of if_then_else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66588 --- Comment #3 from ktkachov at gcc dot gnu.org --- (In reply to Uroš Bizjak from comment #2) (In reply to Uroš Bizjak from comment #1) BTW: x86_64 is missing any form of zero-extended cmove. ... please see [1] how x86_64 implements it (*movsicc_noc_zext). [1] https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01306.html Thanks. As I mentioned in the original post this approach does work. I was just hoping to argue that combine should automatically try both the (zero_extend (if_then_else a b c)) and (if_then_else a (zero_extend b) (zero_extend c)) In fact, wouldn't transforming: (if_then_else a (zero_extend b) (zero_extend c)) into (zero_extend (if_then_else a b c)) be considered a simplification suitable for simplify-rtx.c ?
[Bug middle-end/66588] combine should try transforming if_then_else of zero_extends into zero_extend of if_then_else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66588 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- BTW: x86_64 is missing any form of zero-extended cmove.
[Bug middle-end/66588] combine should try transforming if_then_else of zero_extends into zero_extend of if_then_else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66588 --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Uroš Bizjak from comment #1) BTW: x86_64 is missing any form of zero-extended cmove. ... please see [1] how x86_64 implements it (*movsicc_noc_zext). [1] https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01306.html
