[Bug tree-optimization/120331] match causes an extra assignment sometimes

2025-05-18 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120331

--- Comment #7 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2025-May/683999.html

There was no regressions with this version of the patch and the issue I found
was solved too.

[Bug tree-optimization/120331] match causes an extra assignment sometimes

2025-05-17 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120331

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #61460|0   |1
is obsolete||

--- Comment #6 from Andrew Pinski  ---
Created attachment 61461
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61461&action=edit
New patch which I am testing

We now only undo it for gimple_simplify which takes an `gimple_match_op *`
operand.

[Bug tree-optimization/120331] match causes an extra assignment sometimes

2025-05-17 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120331

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> Created attachment 61460 [details]
> Patch which I am testing

It has one regression though: gcc.dg/builtins-61.c .

That is due to this pattern:
 /* cexp(x+yi) -> exp(x)*cexpi(y).  */
 (for cexps (CEXP)
  exps (EXP)
  cexpis (CEXPI)
  (simplify
   (cexps compositional_complex@0)
   (if (targetm.libc_has_function (function_c99_math_complex, TREE_TYPE (@0)))
(complex
 (mult (exps@1 (realpart @0)) (realpart (cexpis:type@2 (imagpart @0
 (mult @1 (imagpart @2)))


I didn't realize you could capture part of the result and reuse that. That
might be the only pattern which does that.

I guess I need to rethink where to place this part.

[Bug tree-optimization/120331] match causes an extra assignment sometimes

2025-05-17 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120331

--- Comment #4 from Andrew Pinski  ---
Created attachment 61460
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61460&action=edit
Patch which I am testing

[Bug tree-optimization/120331] match causes an extra assignment sometimes

2025-05-17 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120331

--- Comment #3 from Andrew Pinski  ---
I think I have a patch to do this. It undoes the push but only if there is one
statement in the sequence. Though we could extend it later on.

[Bug tree-optimization/120331] match causes an extra assignment sometimes

2025-05-17 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120331

Andrew Pinski  changed:

   What|Removed |Added

Summary|useless NON_LVALUE not  |match causes an extra
   |fully elided by genmatch|assignment sometimes
   |generated code  |
   Keywords||compile-time-hog
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=120206
 Blocks|120206  |
   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
So it is not due to NON_LVALUE.
The problem is we start with:
`MIN_EXPR  > 16`
gets simplified into:
`_t = maxlen_2(D) > 16
 _t & ~0
`

and then ~0 is removed.

There is nothing to undo the removal of _t.

So this is less important than I thought, I will leave it for another day.
It has a small compile time performance issue though.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120206
[Bug 120206] Removal of
forward_propagate_into_gimple_cond/forward_propagate_into_comparison