[Bug tree-optimization/89317] Ineffective code from std::copy

2022-12-11 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:2dc5d6b1e7ec8822f5bd78761962ca2c85d4a2b4

commit r13-4607-g2dc5d6b1e7ec8822f5bd78761962ca2c85d4a2b4
Author: Richard Biener 
Date:   Mon Dec 12 08:13:33 2022 +0100

tree-optimization/89317 - another pattern for >x != p + 4

As seen in the original testcase for PR89317 we are missing
comparison simplification patterns for >x != p + 4.  Fixed
by making an existing one apply.  To make the pattern apply
during CCP we need to simplify ccp_fold to not use GENERIC
folding of conditions but also use GIMPLE folding.

PR tree-optimization/89317
* tree-ssa-ccp.cc (ccp_fold): Handle GIMPLE_COND via
gimple_fold_stmt_to_constant_1.
* match.pd ( !=  + c): Apply to pointer_plus with non-ADDR_EXPR
base as well.

* gcc.dg/tree-ssa/pr89317.c: Amend.

[Bug tree-optimization/89317] Ineffective code from std::copy

2022-12-11 Thread rguenther at suse dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317

--- Comment #12 from rguenther at suse dot de  ---
On Sun, 11 Dec 2022, glisse at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317
> 
> --- Comment #11 from Marc Glisse  ---
> (In reply to Richard Biener from comment #10)
> > Should be fixed in GCC 13.
> 
> If I compile the original testcase with -O3, I get for test2:
> 
>   _1 = this_6(D) + 16;
>   _2 = _6(D)->data1;
>   if (_1 != _2)
> 
> so we should probably also handle comparisons and not just subtractions. For
> this particular testcase, the relevant optimizations still happen and RTL
> cleans up the comparison, so it is ok, but the pattern appears in other PRs
> like PR 106677.

I'll see to add those.

[Bug tree-optimization/89317] Ineffective code from std::copy

2022-12-11 Thread glisse at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317

--- Comment #11 from Marc Glisse  ---
(In reply to Richard Biener from comment #10)
> Should be fixed in GCC 13.

If I compile the original testcase with -O3, I get for test2:

  _1 = this_6(D) + 16;
  _2 = _6(D)->data1;
  if (_1 != _2)

so we should probably also handle comparisons and not just subtractions. For
this particular testcase, the relevant optimizations still happen and RTL
cleans up the comparison, so it is ok, but the pattern appears in other PRs
like PR 106677.

[Bug tree-optimization/89317] Ineffective code from std::copy

2022-12-11 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |13.0

--- Comment #10 from Richard Biener  ---
Should be fixed in GCC 13.

[Bug tree-optimization/89317] Ineffective code from std::copy

2022-12-11 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:d13b86f932ff7b9d8f41483fd869c637b67d4dec

commit r13-4600-gd13b86f932ff7b9d8f41483fd869c637b67d4dec
Author: Richard Biener 
Date:   Sun Dec 11 14:07:34 2022 +0100

tree-optimization/89317 - missed folding of (p + 4) - >d

The PR notices we fail to simplify

  a_4 = _3(D)->data;
  b_5 = x_3(D) + 16;
  _1 = b_5 - a_4;

together with the enabler handling ADDR_EXPR leafs in separate
stmts in match.pd the suggested patterns work.

PR tree-optimization/89317
* match.pd ((p + b) - >c -> b - offsetof(c)): New patterns.

* gcc.dg/tree-ssa/pr89317.c: New testcase.

[Bug tree-optimization/89317] Ineffective code from std::copy

2022-12-11 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317

Richard Biener  changed:

   What|Removed |Added

   Assignee|pinskia at gcc dot gnu.org |rguenth at gcc dot 
gnu.org

--- Comment #8 from Richard Biener  ---
I have a patch in testing for the missed optimization on GIMPLE.

[Bug tree-optimization/89317] Ineffective code from std::copy

2022-12-08 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317

--- Comment #7 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #6)
> Better one:
> struct b { int data[16]; };
> 
> int foo (struct b *x)
> {
>   int *a = x->data;
>   int *b = ((int*)x) + 4;
>   return b - a;
> }

Note we can handle address of a variable case already; that is:
```
struct b { int data[16]; };

int foo (struct b x)
{
  int *a = x.data;
  int *b = ((int*)) + 4;
  return b - a;
}
```
is optimized during ccp1.

[Bug tree-optimization/89317] Ineffective code from std::copy

2022-12-08 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317

--- Comment #6 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #5)
> Reduced testcase for that issue:
> struct { int data[16]; } *x;
> int foo (int n1)
> {
>   int *a = x->data;
>   int *b = ((int*)x) + 4;
>   return b - a;
> }
Better one:
struct b { int data[16]; };

int foo (struct b *x)
{
  int *a = x->data;
  int *b = ((int*)x) + 4;
  return b - a;
}

[Bug tree-optimization/89317] Ineffective code from std::copy

2022-12-08 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||TREE

--- Comment #5 from Andrew Pinski  ---
Note on the trunk, these two functions now produce the same code. BUT we are
still missing a gimple level optimization.

The RTL level can figure out:
  _1 = this_6(D) + 16;
  _2 = _6(D)->data1;
  _19 = _1 - _2;
  __n_20 = _19 /[ex] 2;
  if (_19 > 0)
goto ; [89.00%]
  else
goto ; [11.00%]

That _19 is 16 and the condition is always true.

Reduced testcase for that issue:
struct { int data[16]; } *x;
int foo (int n1)
{
  int *a = x->data;
  int *b = ((int*)x) + 4;
  return b - a;
}

[Bug tree-optimization/89317] Ineffective code from std::copy

2021-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug tree-optimization/89317] Ineffective code from std::copy

2021-09-07 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org

--- Comment #4 from Andrew Pinski  ---
Mine.

After my patch for PR 102216, we get:

  _1 = _6(D)->data1;
  _2 = this_6(D) + 16;
  _19 = _2 - _1;

I suspect if we add:
(simplify
 (pointer_diff (pointer_plus @0 @1) ADDR_EXPR@2)
 (with { poly_int64 diff; }
   (if (ptr_difference_const (@0, @2, ))
(plus { build_int_cst_type (type, diff); } (convert @1)
(simplify
 (pointer_diff ADDR_EXPR@0 (pointer_plus @1 @2))
 (with { poly_int64 diff; }
   (if (ptr_difference_const (@0, @1, ))
(minus { build_int_cst_type (type, diff); } (convert @2)

This will work.

[Bug tree-optimization/89317] Ineffective code from std::copy

2019-02-18 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-18
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug tree-optimization/89317] Ineffective code from std::copy

2019-02-12 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317

--- Comment #3 from Marc Glisse  ---
If we avoid changing the type from int16_t to uint16_t, we get 2 calls to
memmove. They don't get expanded, probably because we fail to simplify the size
to 16 in gimple:
  _1 = [(void *)this_5(D) + 16B];
  _2 = _5(D)->data1;
  _10 = _1 - _2;

[Bug tree-optimization/89317] Ineffective code from std::copy

2019-02-12 Thread bugzi...@poradnik-webmastera.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317

--- Comment #2 from Daniel Fruzynski  ---
Yes, I mean inefficient.

[Bug tree-optimization/89317] Ineffective code from std::copy

2019-02-12 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317

--- Comment #1 from Jonathan Wakely  ---
You mean inefficient, right? The effects are correct as far as I can see.