[RISC-V][PR target/116615] RISC-V: Use default LOGICAL_OP_NON_SHORT_CIRCUIT

[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  <jlaw@ventanamicro.com>