https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116615
--- Comment #14 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jeff Law <l...@gcc.gnu.org>: https://gcc.gnu.org/g:34ae3a992a0cc3240d07d69ff12a664cbb5c8be0 commit r15-4173-g34ae3a992a0cc3240d07d69ff12a664cbb5c8be0 Author: Palmer Dabbelt <pal...@rivosinc.com> Date: Tue Oct 8 07:28:32 2024 -0600 [RISC-V][PR target/116615] RISC-V: Use default LOGICAL_OP_NON_SHORT_CIRCUIT > We have cheap logical ops, so let's just move this back to the default > to take advantage of the standard branch/op hueristics. > > gcc/ChangeLog: > > PR target/116615 > * config/riscv/riscv.h (LOGICAL_OP_NON_SHORT_CIRCUIT): Remove. > --- > There's a bunch more discussion in the bug, but it's starting to smell > like this was just a holdover from MIPS (where maybe it also shouldn't > be set). I haven't tested this, but I figured I'd send the patch to get > a little more visibility. > > I guess we should also kick off something like a SPEC run to make sure > there's no regressions? So as I noted earlier, this appears to be a nice win on the BPI. Testsuite fallout is minimal -- just the one SFB related test tripping at -Os that was also hit by Andrew P's work. After looking at it more closely, the SFB codegen and the codegen after Andrew's work should be equivalent assuming two independent ops can dispatch together. The test actually generates sensible code at -Os. It's the -Os in combination with the -fno-ssa-phiopt that causes problems. I think the best thing to do here is just skip at -Os. That still keeps a degree of testing the SFB path. Tested successfully in my tester. But will wait for the pre-commit tester to render a verdict before moving forward. PR target/116615 gcc/ * config/riscv/riscv.h (LOGICAL_OP_NON_SHORT_CIRCUIT): Remove. gcc/testsuite/ * gcc.target/riscv/cset-sext-sfb.c: Skip for -Os. Co-authored-by: Jeff Law <j...@ventanamicro.com>
