Hi Abe,
> After many years away from contributing to GCC, I am rejoining as a
> "gardener": my intent/plan is to clean up the bug backlog, weeding out
> old bugs that are relatively-easy to fix yet have languished for a long
> time. First for today`s gardening: a documentation-only bug or two
Use the correct names of the D_floating and G_floating data formats as
per the VAX ISA nomenclature[1]. Document the `-md', `-md-float', and
`-mg-float' options.
References:
[1] DEC STD 032-0 "VAX Architecture Standard", Digital Equipment
Corporation, A-DS-EL-00032-00-0 Rev J, December
From: Abe Skolnik
Replace "Target" with "Generate" consistently and place a hyphen in
"double-precision" as this is used as an adjective here.
gcc/ChangeLog:
PR target/79646
* config/vax/vax.opt (md, md-float, mg, mg-float): Correct
descriptions.
---
Changes from v1:
Hi,
As reported in PR target/79646 and fixed by a change proposed by Abe we
have a couple of issues with the descriptions of the VAX floating-point
format options in the option definition file. Additionally most of these
options are not documented in the manual.
This mini patch series
https://gcc.gnu.org/g:314448fc65f40c98ee8bc02dfb54ea49d2f2c60d
commit r15-844-g314448fc65f40c98ee8bc02dfb54ea49d2f2c60d
Author: Maciej W. Rozycki
Date: Mon May 27 05:07:32 2024 +0100
VAX/doc: Fix issues with FP format option documentation
Use the correct names of the D_floating
https://gcc.gnu.org/g:a7f6543f21303583356fd2d2d1805bffbecc1bc5
commit r15-843-ga7f6543f21303583356fd2d2d1805bffbecc1bc5
Author: Abe Skolnik
Date: Mon May 27 05:07:32 2024 +0100
vax: Fix descriptions of the FP format options [PR79646]
Replace "Target" with "Generate" consistently
On Sun, 14 Jan 2024, Jeff Law wrote:
> The condition for the pattern looks like this:
>
> "ISA_HAS_MIPS16E2"
>
> And if you dig into ISA_HAS_MIPS16E2:
>
> /* The MIPS16e V2 instructions are available. */
> #define ISA_HAS_MIPS16E2 (TARGET_MIPS16 && TARGET_MIPS16E2 \
>
On Fri, 16 Feb 2024, Maciej W. Rozycki wrote:
> On Fri, 16 Feb 2024, Jakub Jelinek wrote:
>
> > > There is no function prologue to optimise in the VAX case, because all
> > > the frame setup has already been made by the CALLS instruction itself in
> > &g
On Fri, 16 Feb 2024, Jakub Jelinek wrote:
> > There is no function prologue to optimise in the VAX case, because all
> > the frame setup has already been made by the CALLS instruction itself in
> > the caller. The first machine instruction of the callee is technically
> > already past the
On Fri, 16 Feb 2024, Segher Boessenkool wrote:
> > Conversely no heuristics is required to unwind VAX frames, because they
> > are fixed in layout by hardware, fully self-described, and with the
> > hardware frame pointer always available.
>
> The downside of the VAX situation of course is
On Thu, 15 Feb 2024, Paul Koning wrote:
> > On May 15, 2023, at 5:09 PM, Maciej W. Rozycki wrote:
> >
> > ...
> >
> > I may choose to implement a non-DWARF unwinder instead, as the VAX stack
> > frame is always fully described by the hardware and there
sparc port Eric Botcazou
v850 port Nick Clifton
vax port Matt Thomas
-vax port Maciej W. Rozycki
+vax port Maciej W. Rozycki
visium portEric Botcazou
x86
Hi Ben,
This has fallen between the cracks.
On Mon, 9 Oct 2023, Ben Boeckel wrote:
> On Mon, Oct 09, 2023 at 20:12:01 +0100, Maciej W. Rozycki wrote:
> > I'm seeing these tracebacks for several cases across the G++ testsuite:
> >
> > Executing on host: python3 -
On Wed, 3 Jan 2024, Hans-Peter Nilsson wrote:
> > > Hmm. I think it would be more correct to emphasize that the
> > > existing dg-timeout-factor affects both the tool execution *and*
> > > the test execution, whereas your new dg-test-timeout-factor only
> > > affects the test execution. (And
On Wed, 24 Jan 2024, Jeff Law wrote:
> > Do we have consensus now to move forward with this change as posted? I'd
> > like to get these patches ticked off ASAP.
> I think it should move forward. I think having the RTL tests deals with
> Andrew's concern and the testcase adjustment has value
On Tue, 16 Jan 2024, Maciej W. Rozycki wrote:
> > I don't have a strong opinion on this. I certainly see Andrew's point, but
> > it's also the case that if some work earlier in the RTL or gimple pipeline
> > comes along and compromises the test, then we'd see th
Add RTL tests, for RV64 and RV32 where appropriate, corresponding to the
existing cset-sext.c tests. They have been produced from RTL code as at
the entry of the "ce1" pass for the respective cset-sext.c tests built
at -O3.
gcc/testsuite/
* gcc.target/riscv/cset-sext-rtl.c:
Add a pair of RTL tests, for RV64 and RV32 respectively, corresponding
to the existing pr105314.c test. They have been produced from RTL code
as at the entry of the "ce1" pass for pr105314.c compiled at -O3.
gcc/testsuite/
* gcc.target/riscv/pr105314-rtl.c: New file.
*
Hi,
As discussed previously here are a bunch of RTL if-conversion testcases
corresponding to and produced from existing pr105314.c and cset-sext.c C
testcases. Verified with RV64 and RV32. OK to apply?
Maciej
On Tue, 16 Jan 2024, Jeff Law wrote:
> > It's not clear to me what you mean by an "RTL testcase", i.e. how you'd
> > see the testcase changed (or an additional one produced instead) and why,
> > please elaborate. Right now we verify that branches are absent from
> > output, but not how that
On Fri, 12 Jan 2024, Andrew Pinski wrote:
> > Verify that if-conversion succeeded through noce_try_store_flag_mask, as
> > per PR rtl-optimization/105314, tightening the test case and making it
> > explicit.
> >
> > gcc/testsuite/
> > * gcc.target/riscv/pr105314.c: Scan the RTL
Verify that if-conversion succeeded through noce_try_store_flag_mask, as
per PR rtl-optimization/105314, tightening the test case and making it
explicit.
gcc/testsuite/
* gcc.target/riscv/pr105314.c: Scan the RTL "ce1" pass too.
---
gcc/testsuite/gcc.target/riscv/pr105314.c |
The optimization levels pr105314.c is iterated over are needlessly
overridden with "-O2", limiting the coverage of the test case to that
level, perhaps with additional options the original optimization level
has been supplied with. We could prevent the extra iterations other
than "-O2" from
Hi,
Here's a pair of further pr105314.c changes I came up with in the course
of recent RISC-V if-conversion work. It's not entirely clear to me what
our policy is for Stages 3 and 4 when it comes to testsuite cleanups or
improvements, but I think it's worth sharing these updates anyway.
OK
Add terminating `/' character missing from one of the test harness
command clauses in pr105314.c. This causes no issue with compilation
owing to another comment immediately following, but would cause a:
pr105314.c:3:1: warning: "/*" within comment [-Wcomment]
message if warnings were enabled.
On Tue, 9 Jan 2024, Jeff Law wrote:
> > Depending on how you look at it you may qualify this as a bug fix (for
> > the commit referred; it's surely rare enough a case I missed in original
> > testing) or a missed optimisation. Either way it's a narrow-scoped very
> > small change, almost an
Complement commit c1e8cb3d9f94 ("RISC-V: Rework branch costing model for
if-conversion") and also handle extraneous sign extend operations that
are sometimes produced by `noce_try_cmove_arith' instead of zero extend
operations, making branch costing consistent. It is unclear what the
On Wed, 3 Jan 2024, Hans-Peter Nilsson wrote:
> > The test execution timeout is different from the tool execution timeout
> > where it is GCC execution that is being guarded against taking excessive
> > amount of time on the test host rather than the resulting test case
> > executable run on
On Mon, 11 Dec 2023, Richard Sandiford wrote:
> > It all seems a bit hackish. I don't think ports have had much success
> > using 'p' through the decades. I think I generally ended up having to
> > go with distinct constraints rather than relying on 'p'.
> >
> > OK for the trunk, but ewww.
>
Add support for the `test_timeout_factor' global variable letting a test
case scale the wait timeout used for code execution. This is useful for
particularly slow test cases for which increasing the wait timeout
globally would be excessive.
* baseboards/qemu.exp (qemu_load): Handle
Add support for the `dg-test-timeout-factor' keyword letting a test
case scale the wait timeout used for code execution, analogously to
`dg-timeout-factor' used for code compilation. This is useful for
particularly slow test cases for which increasing the wait timeout
globally would be excessive.
Hi,
This patch quasi-series makes it possible for individual test cases
identified as being slow to request more time via the GCC test harness by
providing a test execution timeout factor, applied to the tool execution
timeout set globally for all the test cases. This is to avoid excessive
On Mon, 11 Dec 2023, Jeff Law wrote:
> > This happened with the late-combine pass that I posted in October:
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634166.html
> > which in turn triggered an error from aarch64_print_operand_address.
> >
> > This patch takes the (hopefully)
On Wed, 8 Nov 2023, Kito Cheng wrote:
> OK, then LGTM, thanks for the explanation :)
Please don't top-post on a GCC mailing list (and preferably in off-list
replies to such mailing list messages unless it's been agreed to somehow
with the participants), as it makes it difficult to make
On Wed, 29 Nov 2023, Rainer Orth wrote:
> Tested on sparc-sun-solaris2.11, installed on trunk.
Thank you for fixing it.
Maciej
On Tue, 28 Nov 2023, Jeff Law wrote:
> FWIW, I was looking at a regression with our internal tests after your
> changes. It was quite nice to see how well twiddling -mbranch-cost
> correlated to how many instructions we would allow in a conditional move
> sequence.
I'm a bit concerned though
On Sun, 19 Nov 2023, Jeff Law wrote:
> So this is a more gradual lowering of the FP branches to allow ifcvt to do a
> better job. Seems generally reasonable. I don't expect that we're missing
> any significant simplifications, though I probably could construct a missed
> CSE/GCSE if I worked at
On Sun, 19 Nov 2023, Jeff Law wrote:
> > Lift this restriction and only bail out if a non-word-mode integer
> > condition has been requested, as we cannot handle this specific case
> > owing to machine instruction set restriction. We already take care of
> > the non-integer, non-floating-point
On Sun, 19 Nov 2023, Jeff Law wrote:
> > The reason to XFAIL SImode tests for RV64 targets is the compiler thinks
> > it has to sign-extend addends, which causes if-conversion to give up.
> WRT extension and causing if-conversion to give up. Yes, it's a real issue.
> In fact when we had Jivan do
On Sun, 19 Nov 2023, Jeff Law wrote:
> Is this an improvement over what if-convert creates for a conditional add or
> is the goal to expose the sequence earlier in the pipeline rather than waiting
> for ifcvt?
TBH I haven't ever seen if-convert eliminate a branch here without this
pattern
On Sun, 19 Nov 2023, Jeff Law wrote:
> OK. Just curious are y'all seeing significant interest in this case from
> customers or is this more a case of rounding out the implementation to cover
> all potential possibilities?
As in the cover letter: we have a case where the pipeline seems to imply
On Sun, 19 Nov 2023, Kito Cheng wrote:
> Just one minor comment, I think we don't really need to check rv64 or
> rv32 for those compiled without any header file test, but I am fine
> with that.
We need to set `-march=' differently depending on whether verifying for
rv64 or rv32, and then we
On Sun, 19 Nov 2023, Jeff Law wrote:
> As I suspect you know a big part of the problem here is that BRANCH_COST and
> rtx_cost don't have any common scale and thus trying to compare BRANCH_COST to
> RTX_COST doesn't have well defined meaning.
We do have preexisting places using COSTS_N_INSNS
On Wed, 22 Nov 2023, Richard Earnshaw (lists) wrote:
> > Use non-capturing parentheses for the subexpressions used with
> > `scan-assembler-times', to avoid a quirk with double-counting.
> >
> > gcc/testsuite/
> > * gcc.target/aarch64/ccmp_1.c: Use non-capturing parentheses
> >
Use non-capturing parentheses for the subexpressions used with
`scan-assembler-times', to avoid a quirk with double-counting.
gcc/testsuite/
* gcc.target/aarch64/ccmp_1.c: Use non-capturing parentheses
with `scan-assembler-times'.
---
Hi,
Here's another one. I
On Mon, 13 Nov 2023, Jeff Law wrote:
> > > The testcase is generic enough I thought it wouldn't hurt to place it in
> > > a generic part of the testsuite, where it has been verified to pass with
> > > the `powerpc64le-linux-gnu', `riscv64-linux-gnu', and `vax-netbsdelf'
> > > targets. I'm fine
On Sun, 19 Nov 2023, Jeff Law wrote:
> > Verified with the `riscv64-linux-gnu' target and the C language
> > testsuite. OK to apply?
> Not sure why it is the way it is -- I walked back to Zdenek's change which
> introduced the scan-assembler-times and nothing about the -inline argument.
I
Use non-capturing parentheses for the subexpressions used with
`scan-assembler-times', to avoid a quirk with double-counting.
gcc/testsuite/
* gcc.target/arm/pr53447-5.c: Use non-capturing parentheses with
`scan-assembler-times'.
---
Hi,
The `scan-assembler-times'
On Sun, 19 Nov 2023, Jeff Law wrote:
> > gcc/
> > * config/riscv/riscv-protos.h (riscv_expand_float_scc): Add
> > `invert_ptr' parameter.
> > * config/riscv/riscv.cc (riscv_emit_float_compare): Add NE
> > inversion handling.
> > (riscv_expand_float_scc): Pass `invert_ptr'
On Mon, 20 Nov 2023, Richard Biener wrote:
> > > ok
> >
> > Thank you for your review, but I think I need a general maintainer's ack
> > for this one.
>
> OK.
I have committed this change now, thank you for your review.
Maciej
On Sun, 19 Nov 2023, Jeff Law wrote:
> > Verified with the `riscv64-linux-gnu' target and the C language
> > testsuite. OK to apply?
> OK
Applied now, thank you for your review.
Maciej
On Sun, 19 Nov 2023, Kito Cheng wrote:
> ok
Thank you for your review, but I think I need a general maintainer's ack
for this one.
Maciej
We have an issue with `scan-assembler-times' handling expressions using
subexpressions as produced by capturing parentheses `()' in an odd way,
and one that is inconsistent with `scan-assembler', `scan-assembler-not',
etc. The problem comes from calling `regexp' with `-inline -all', which
Remove our RISC-V-specific `order_operator' predicate, which is exactly
the same as generic `ordered_comparison_operator' one.
gcc/
* config/riscv/predicates.md (order_operator): Remove predicate.
* config/riscv/riscv.cc (riscv_rtx_costs): Update accordingly.
*
On Sat, 18 Nov 2023, Jeff Law wrote:
> Is this dependent on any of the other patches in this series? Or is it
> independent and ready to go as-is? I ask becuase it's marked as 13/44 and I
> haven't seen the other 43 patches in the series :-)
>
> If it's independent and been tested, then it's
Verify, for the generic floating-point NE conditional-add operation,
that if-conversion triggers via `noce_try_addcc' at `-mbranch-cost=3'
setting, which makes branchless code sequences emitted by if-conversion
cheaper than their original branched equivalents, and that extraneous
instructions
Verify, for the generic floating-point NE conditional-add operation,
that if-conversion does *not* trigger at `-mbranch-cost=2' setting,
which makes original branched code sequences cheaper than their
branchless equivalents if-conversion would emit.
gcc/testsuite/
*
Verify, for the floating-point NE conditional-move operation, that
if-conversion triggers via `noce_try_cmove' at the respective
sufficiently high `-mbranch-cost=' settings that make branchless code
sequences produced by if-conversion cheaper than their original branched
equivalents, and that
Verify, for generic, Ventana and Zicond targets and the floating-point
NE conditional-move operation, that if-conversion does *not* trigger at
the respective sufficiently low `-mbranch-cost=' settings that make
original branched code sequences cheaper than their branchless
equivalents
Verify, for generic floating-point conditional-add operations that have
a corresponding conditional-set machine instruction, that if-conversion
triggers via `noce_try_addcc' at `-mbranch-cost=3' setting, which makes
branchless code sequences emitted by if-conversion cheaper than their
original
We have no FNE.fmt machine instructions, but we can emulate them for the
purpose of conditional-move and conditional-add operations by using the
respective FEQ.fmt instruction and then swapping the data input operands
or complementing the mask for the conditional addend respectively, so
update
Verify, for generic floating-point conditional-move operations that have
a corresponding conditional-set machine instruction, that if-conversion
does *not* trigger at `-mbranch-cost=4' setting, which makes original
branched code sequences cheaper than their branchless equivalents
if-conversion
Verify, for generic floating-point conditional-add operations that have
a corresponding conditional-set machine instruction, that if-conversion
does *not* trigger at `-mbranch-cost=2' setting, which makes original
branched code sequences cheaper than their branchless equivalents
if-conversion
We have floating-point coditional-set machine instructions for a subset
of FP comparisons, so avoid going through a comparison against constant
zero in `riscv_expand_float_scc' where not necessary, preventing an
extraneous RTL instruction from being produced that counts against the
cost of the
A subsequent change to enable the processing of conditional moves on a
floating-point condition by `riscv_expand_conditional_move' will cause
`riscv_expand_float_scc' to be called for word-mode target RTX with RV64
targets. In that case an invalid insn such as:
(insn 25 24 0 (set (reg:DI 141)
Verify, for generic floating-point conditional-move operations that have
a corresponding conditional-set machine instruction, that if-conversion
triggers (via `cond_move_convert_if_block', which doesn't report) at
`-mbranch-cost=5' setting, which makes branchless code sequences emitted
by
Do not expand floating-point conditional-branch RTL instructions right
away that use a comparison operation that is either directly available
as a machine conditional-set instruction or is NE, which can be emulated
by EQ. This is so that if-conversion sees them in their original form
and can
Provide RTL expansion of conditional-add operations for generic targets
using a suitable sequence of base integer machine instructions according
to cost evaluation by if-conversion. Use existing `-mmovcc' command
line option to enable this transformation.
gcc/
*
In `riscv_expand_conditional_move' we only let integer conditions
through at the moment, even though code has already been prepared to
handle floating-point conditions as well.
Lift this restriction and only bail out if a non-word-mode integer
condition has been requested, as we cannot handle
Verify, for generic integer conditional-add operations, if-conversion
to trigger via `noce_try_addcc' at the respective sufficiently high
`-mbranch-cost=' settings that make branchless code sequences produced
by if-conversion cheaper than their original branched equivalents, and,
where applicable,
Verify, for generic integer conditional-move operations, if-conversion
*not* to trigger at the respective sufficiently low `-mbranch-cost='
settings that make original branched code sequences cheaper than their
branchless equivalents if-conversion would emit. Cover all integer
relational
Verify, for generic integer conditional-add operations, if-conversion
*not* to trigger at the respective sufficiently low `-mbranch-cost='
settings that make original branched code sequences cheaper than their
branchless equivalents if-conversion would emit. Cover all integer
relational
Verify, for generic integer conditional-move operations, if-conversion
to trigger via `noce_try_cmove' at the respective sufficiently high
`-mbranch-cost=' settings that make branchless code sequences produced
by if-conversion cheaper than their original branched equivalents, and,
where
Provide RTL expansion of conditional-move operations for generic targets
using a suitable sequence of base integer machine instructions according
to cost evaluation by if-conversion. Add `-mmovcc' command line option
to enable this transformation, off by default.
For the generic sequences
Verify, for T-Head targets and the non-equality integer conditional-move
operations, that if-conversion triggers via `noce_try_cmove' at
`-mbranch-cost=2' setting, which makes branchless code sequences
produced by if-conversion cheaper than their original branched
equivalents, and that
Add a `riscv_emit_unary' helper for unary operations, complementing
`riscv_emit_binary'.
gcc/
* config/riscv/riscv-protos.h (riscv_emit_unary): New prototype.
* config/riscv/riscv.cc (riscv_emit_unary): New function.
---
gcc/config/riscv/riscv-protos.h |1 +
Verify, for T-Head targets and the non-equality integer conditional-move
operations, that if-conversion does *not* trigger at `-mbranch-cost=1'
setting, which makes original branched code sequences cheaper than their
branchless equivalents if-conversion would emit.
gcc/testsuite/
Code in `riscv_expand_conditional_move' for Ventana and Zicond targets
seems like bolted on as an afterthought rather than properly merged so
as to handle all the cases together.
Fold the existing code pieces together then (observing that for short
forward branch targets no integer comparisons
There is no need for the requirement for conditional-move data input
operands to be stricter for T-Head targets than for short forward branch
targets and limit them to registers only. They are keyed according to
the `sfb_alu_operand' predicate, which lets certain constants through.
Such
There is no need for the requirement for conditional-move comparison
operands to be stricter for T-Head targets than for other targets and
limit them to registers only. Constants will be reloaded if required
just as with branches or other-target conditional-move operations and
there is no
Verify, for Ventana and Zicond targets and the GEU and LEU
conditional-move operations, that if-conversion does *not* trigger at
`-mbranch-cost=3' setting, which makes original branched code sequences
cheaper than their branchless equivalents if-conversion would emit.
gcc/testsuite/
Verify, for Ventana and Zicond targets and the equality conditional-move
operations, that if-conversion triggers via `noce_try_cmove' at the
respective sufficiently high `-mbranch-cost=' settings that make
branchless code sequences produced by if-conversion cheaper than their
original branched
Verify, for Ventana and Zicond targets and the equality conditional-move
operations, that if-conversion does *not* trigger at the respective
sufficiently low `-mbranch-cost=' settings that make original branched
code sequences cheaper than their branchless equivalents if-conversion
would emit.
In the non-zero case there is no need for the conditional value used by
Ventana and Zicond integer conditional operations to be specifically 1.
Regardless we canonicalize it by producing an extraneous conditional-set
operation, such as with the sequence below:
(insn 22 6 23 2 (set (reg:DI 141)
Update `riscv_expand_conditional_move' and handle the missing GEU and
LEU operators there, avoiding an extraneous conditional set operation,
such as with this output:
sgtua0,a0,a1
seqza1,a0
czero.eqz a3,a3,a1
czero.nez a1,a2,a1
or
Verify, for Ventana and Zicond targets and the GEU and LEU
conditional-move operations, that if-conversion triggers via
`noce_try_cmove' at `-mbranch-cost=4' setting, which makes branchless
code sequences produced by if-conversion cheaper than their original
branched equivalents, and that
Verify, for Ventana and Zicond targets and the ordered floating-point
conditional-move operations that already work as expected, that
if-conversion does *not* trigger at `-mbranch-cost=2' setting, which
makes original branched code sequences cheaper than their branchless
equivalents
Verify, for T-Head, Ventana and Zicond targets and the integer
conditional-move operations that already work as expected, if-conversion
to trigger via `noce_try_cmove' at the respective sufficiently high
`-mbranch-cost=' settings that make branchless code sequences produced
by if-conversion
Verify, for T-Head, Ventana and Zicond targets and the integer
conditional-move operations that already work as expected, that
if-conversion does *not* trigger at the respective sufficiently low
`-mbranch-cost=' settings that make original branched code sequences
cheaper than their branchless
The generic branch costing model for if-conversion assumes a fixed cost
of COSTS_N_INSNS (2) for a conditional branch, and that one half of that
cost comes from a preceding condition-set instruction, such as with
MODE_CC targets, and then the other half of that cost is for the actual
branch
Use `nullptr' for consistency rather than 0 to initialize `invert_ptr'.
gcc/
* config/riscv/riscv.cc (riscv_expand_conditional_move): Use
`nullptr' rather than 0 to initialize a pointer.
---
gcc/config/riscv/riscv.cc |2 +-
1 file changed, 1 insertion(+), 1
Just choose between EQ and NE at `gen_rtx_fmt_ee' invocation, removing
an extraneous variable only referred once and improving code clarity.
gcc/
* config/riscv/riscv.cc (riscv_expand_conditional_move): Remove
extraneous variable for EQ vs NE operation selection.
---
Use `mode0' and `mode1' shorthands respectively for `GET_MODE (op0)' and
`GET_MODE (op1)' to improve code readability.
gcc/
* config/riscv/riscv.cc (riscv_expand_conditional_move): Use
`mode0' and `mode1' for `GET_MODE (op0)' and `GET_MODE (op1)'.
---
In `riscv_expand_conditional_move' `mode' is initialized right away from
`GET_MODE (dest)', so remove needless references that refrain from using
the local variable.
gcc/
* config/riscv/riscv.cc (riscv_expand_conditional_move): Use
`mode' for `GET_MODE (dest)'
For the NEED_EQ_NE_P `riscv_emit_int_compare' is documented to only emit
EQ or NE comparisons against zero, however it does not catch incorrect
use where a non-equality comparison has been requested and falls through
to the general case then. Add a safety guard to catch such a case then.
Our `movcc' expander is no longer specific to short forward branch
targets, so move its associated comment accordingly.
gcc/
* config/riscv/riscv.md (movcc): Move comment on SFB
patterns over to...
(*movcc): ... here.
---
gcc/config/riscv/riscv.md |4 ++--
1
Verify, for short forward branch targets and the conditional-move
operations that already work as expected, that if-conversion triggers
via `noce_try_cmove' already at `-mbranch-cost=1' and that extraneous
instructions such as SNEZ, etc. are not present in output. Cover all
integer relational
Add generic execution tests for expressions that are expected to expand
to conditional-move and conditional-add operations where supported. To
ensure no corner case escapes all relational operators are extensively
covered for integer comparisons and all ordered operators are covered
for
Hi,
This patch series has come out from a simple change to add generic
conditional-move and conditional-add expansions for a yet-out-of-tree
target, which has relatively expensive branches and no conditional
operations beyond the base architecture conditional-set instructions. At
one point
Verify, for short forward branch, T-Head, Ventana and Zicond targets and
the ordered floating-point conditional-move operations that already work
as expected, that if-conversion triggers via `noce_try_cmove' at the
respective sufficiently high `-mbranch-cost=' settings that make
branchless
1 - 100 of 927 matches
Mail list logo
