[Bug c/111760] New: risc-v regression: COND_LEN_* incorrect fold/simplify in middle-end

[Bug c/111760] New: risc-v regression: COND_LEN_* incorrect fold/simplify in middle-end

[juzhe.zhong at rivai dot ai]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760

            Bug ID: 111760
           Summary: risc-v regression: COND_LEN_* incorrect fold/simplify
                    in middle-end
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: juzhe.zhong at rivai dot ai
  Target Milestone: ---

FAIL: gcc.dg/vect/vect-cond-arith-2.c -flto -ffat-lto-objects  scan-tree-dump
optimized " = \\.COND_(LEN_)?SUB"
FAIL: gcc.dg/vect/vect-cond-arith-2.c scan-tree-dump optimized " =
\\.COND_(LEN_)?SUB"

https://godbolt.org/z/hEz51qf6a

double __GIMPLE (ssa, startwith("loop"))
neg_xi (double *x)
{
  int i;
  long unsigned int index;
  long unsigned int offset;
  double * xi_ptr;
  double xi;
  double neg_xi;
  double res;
  unsigned int ivtmp;

 __BB(5):
  goto __BB2;

 __BB(2):
  res_1 = __PHI (__BB5: 0.0, __BB3: res_2);
  i_4 = __PHI (__BB5: 0, __BB3: i_5);
  ivtmp_6 = __PHI (__BB5: 100U, __BB3: ivtmp_7);
  index = (long unsigned int) i_4;
  offset = index * 8UL;
  xi_ptr = x_8(D) + offset;
  xi = *xi_ptr;
  neg_xi = -xi;
  res_2 = neg_xi + res_1;
  i_5 = i_4 + 1;
  ivtmp_7 = ivtmp_6 - 1U;
  if (ivtmp_7 != 0U)
    goto __BB3;
  else
    goto __BB4;

 __BB(3):
  goto __BB2;

 __BB(4):
  res_3 = __PHI (__BB2: res_2);
  return res_3;
}

There is no COND_LEN_ADD IR here which is incorrect.

[Bug c/111760] risc-v regression: COND_LEN_* incorrect fold/simplify in middle-end

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 111761 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/111760] risc-v regression: COND_LEN_* incorrect fold/simplify in middle-end

[rdapp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760

Robin Dapp <rdapp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rdapp at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org

--- Comment #2 from Robin Dapp <rdapp at gcc dot gnu.org> ---
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?

[Bug tree-optimization/111760] risc-v regression: COND_LEN_* incorrect fold/simplify in middle-end

[juzhe.zhong at rivai dot ai]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760

--- Comment #3 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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

[juzhe.zhong at rivai dot ai]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760

--- Comment #5 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(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

[rdapp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760

--- Comment #6 from Robin Dapp <rdapp at gcc dot gnu.org> ---
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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsandifo at gcc dot gnu.org

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Robin Dapp <rdapp@gcc.gnu.org>:

https://gcc.gnu.org/g:0c42741ad95af3a1e3ac07350da4c3a94865ed63

commit r14-5151-g0c42741ad95af3a1e3ac07350da4c3a94865ed63
Author: Robin Dapp <rdapp@ventanamicro.com>
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_<mode><vm>): 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

[juzhe.zhong at rivai dot ai]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760

JuzheZhong <juzhe.zhong at rivai dot ai> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #9 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Fixed