[Bug tree-optimization/111760] risc-v regression: COND_LEN_* incorrect fold/simplify in middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760 JuzheZhong changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from JuzheZhong --- Fixed
[Bug tree-optimization/111760] risc-v regression: COND_LEN_* incorrect fold/simplify in middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760 --- Comment #8 from CVS Commits --- The master branch has been updated by Robin Dapp : https://gcc.gnu.org/g:0c42741ad95af3a1e3ac07350da4c3a94865ed63 commit r14-5151-g0c42741ad95af3a1e3ac07350da4c3a94865ed63 Author: Robin Dapp Date: Wed Oct 25 22:19:43 2023 +0200 internal-fn: Add VCOND_MASK_LEN. In order to prevent simplification of a COND_OP with degenerate mask (CONSTM1_RTX) into just an OP in the presence of length masking this patch introduces a length-masked analog to VEC_COND_EXPR: IFN_VCOND_MASK_LEN. It also adds new match patterns that allow the combination of unconditional unary, binary and ternay operations with the VCOND_MASK_LEN into a conditional operation if the target supports it. gcc/ChangeLog: PR tree-optimization/111760 * config/riscv/autovec.md (vcond_mask_len_): Add expander. * config/riscv/riscv-protos.h (enum insn_type): Add. * config/riscv/riscv-v.cc (needs_fp_rounding): Add !pred_mov. * doc/md.texi: Add vcond_mask_len. * gimple-match-exports.cc (maybe_resimplify_conditional_op): Create VCOND_MASK_LEN when length masking. * gimple-match.h (gimple_match_op::gimple_match_op): Always initialize len and bias. * internal-fn.cc (vec_cond_mask_len_direct): Add. (direct_vec_cond_mask_len_optab_supported_p): Add. (internal_fn_len_index): Add VCOND_MASK_LEN. (internal_fn_mask_index): Ditto. * internal-fn.def (VCOND_MASK_LEN): New internal function. * match.pd: Combine unconditional unary, binary and ternary operations into the respective COND_LEN operations. * optabs.def (OPTAB_D): Add vcond_mask_len optab. gcc/testsuite/ChangeLog: * gcc.dg/vect/vect-cond-arith-2.c: No vect cost model for riscv_v.
[Bug tree-optimization/111760] risc-v regression: COND_LEN_* incorrect fold/simplify in middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760 Richard Biener changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #7 from Richard Biener --- But Richard S. invented the "conditional" op stuff in folding (I was also waiting for him to look at Robins patch).
[Bug tree-optimization/111760] risc-v regression: COND_LEN_* incorrect fold/simplify in middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760 --- Comment #6 from Robin Dapp --- Yes, thanks for filing this bug separately. The patch doesn't disable all of those optimizations, of course I paid special attention not mess up with them. The difference here is that we valueize, add statements to *seq and the last statement is a _30 = bla. Then we'd either need to "_30 = COND_LEN_MOVE bla" or predicate bla itself. Surely there is a better way.
[Bug tree-optimization/111760] risc-v regression: COND_LEN_* incorrect fold/simplify in middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760
--- Comment #5 from JuzheZhong ---
(In reply to Robin Dapp from comment #2)
> https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629904.html
>
> prevents the wrong code but still leaves us with a redundant negation (and
> it is not the only missed optimization of that kind):
>
> vect_neg_xi_14.4_23 = -vect_xi_13.3_22;
> vect_res_2.5_24 = .COND_LEN_ADD ({ -1, ... }, vect_res_1.0_17,
> vect_neg_xi_14.4_23, vect_res_1.0_17, _29, 0);
>
> That's because my "hackaround" doesn't recognize a valueized sequence
> _30 = vect_res_1.0_17 - vect_xi_13.3_22;
>
> Of course I could (reverse valueize) recognize that again and convert it to
> a COND_LEN... but that doesn't seem elegant at all. There must be a simpler
> way that I'm missing entirely right now. That said, converting the last
> statement of such a sequence should be sufficient?
Yeah. That's what I want to point it out. Your patch will disable the
optimization
I made in GIMPLE_FOLD for COND_LEN_xxx.
I am not sure how to fix it, I think we need Richi's help for that since he
knows
the GIMPLE FOLD stuff the best.
[Bug tree-optimization/111760] risc-v regression: COND_LEN_* incorrect fold/simplify in middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760 --- Comment #4 from Andrew Pinski --- (In reply to JuzheZhong from comment #3) > (In reply to Andrew Pinski from comment #1) > > *** Bug 111761 has been marked as a duplicate of this bug. *** > > Oh. So sorry about that. I don't know why I file 2 consecutive bugs here. > > Really sorry for my mistake to file duplicate bugs. > > I guess my internet issue make such mistake :). Bugzilla sometimes does that, I have had it happen on me more than once. that is why I didn't really ask why you filed it twice even.
[Bug tree-optimization/111760] risc-v regression: COND_LEN_* incorrect fold/simplify in middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760 --- Comment #3 from JuzheZhong --- (In reply to Andrew Pinski from comment #1) > *** Bug 111761 has been marked as a duplicate of this bug. *** Oh. So sorry about that. I don't know why I file 2 consecutive bugs here. Really sorry for my mistake to file duplicate bugs. I guess my internet issue make such mistake :).
[Bug tree-optimization/111760] risc-v regression: COND_LEN_* incorrect fold/simplify in middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
--- Comment #2 from Robin Dapp ---
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629904.html
prevents the wrong code but still leaves us with a redundant negation (and it
is not the only missed optimization of that kind):
vect_neg_xi_14.4_23 = -vect_xi_13.3_22;
vect_res_2.5_24 = .COND_LEN_ADD ({ -1, ... }, vect_res_1.0_17,
vect_neg_xi_14.4_23, vect_res_1.0_17, _29, 0);
That's because my "hackaround" doesn't recognize a valueized sequence
_30 = vect_res_1.0_17 - vect_xi_13.3_22;
Of course I could (reverse valueize) recognize that again and convert it to a
COND_LEN... but that doesn't seem elegant at all. There must be a simpler way
that I'm missing entirely right now. That said, converting the last statement
of such a sequence should be sufficient?
