[Bug tree-optimization/19639] New: Funny (horrible) code for empty destructor

[Bug tree-optimization/19639] New: Funny (horrible) code for empty destructor

[rguenth at tat dot physik dot uni-tuebingen dot de]

The following simple testcase

struct Foo { ~Foo() {} int i; };
struct NonPod { Foo foo[2]; };
void foo(void)
{
        NonPod x;
}

produces(!) at -O2

_Z3foov:
.LFB5:
        pushl   %ebp
.LCFI0:
        movl    %esp, %ebp
.LCFI1:
        subl    $16, %esp
.LCFI2:
        leal    -2(%ebp), %edx
        movl    %ebp, %eax
        .p2align 4,,15
.L4:
        decl    %eax
        cmpl    %edx, %eax
        jne     .L4
        leave
        ret

yay!  Looking at the optimized tree-dump, it contains a funny loop:

void foo() ()
{
  struct Foo * const this;
  register struct Foo * D.1621;
  struct Foo[2] * D.1620;
  struct NonPod x;

<bb 0>:
  if (&x.foo[2] == &x.foo) goto <L6>; else goto <L14>;

<L14>:;
  this = &x.foo[2];

<L2>:;
  this = this - 1;
  if (this == &x.foo) goto <L6>; else goto <L2>;

<L6>:;
  return;

}

which is roughly what is generated initially by the C++ frontend
for the dtor:

;; Function NonPod::~NonPod() (_ZN6NonPodD1Ev *INTERNAL* )
;; enabled by -tree-original

{
  <<< Unknown tree: if_stmt  
  1

   >>>
;
  try
    {

    }
  finally
    {
      {
        register struct Foo * D.1599;

        (if (&((struct NonPod *) this)->foo != 0B)
          {
            (void) (D.1599 = &((struct NonPod *) this)->foo + 2);
            while (1)
              {
                if (&((struct NonPod *) this)->foo == D.1599) break;
                (void) (D.1599 = D.1599 - 1);;
                __comp_dtor  (NON_LVALUE_EXPR <D.1599>);;
              };
          }
        else
          {
            0
          });
      }
    }
}
<D1598>:;

Note the same happens for empty struct Foo, but even avoiding
the ambiguous(?) &this->foo[2] - &this->foo[1] doesn't help.

The RTL unroller, if enabled, gets rid of the most ugly stuff from above,
but appearantly the tree loop optimizer does not know how to handle this
loop.

_Z3foov:
.LFB5:
        pushl   %ebp
.LCFI0:
        movl    %esp, %ebp
.LCFI1:
        subl    $16, %esp
.LCFI2:
        movl    %ebp, %esp
        popl    %ebp
        ret

-- 
           Summary: Funny (horrible) code for empty destructor
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rguenth at tat dot physik dot uni-tuebingen dot de
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-26 13:57 -------
Well there are multiple problems in this bug.
One is that empty loops are not removed (PR 17640).  The only problem
Another is that we don't fold "(&x.foo[2] == &x.foo)" to false
And "&x.foo[2] - 4B" to "&x.foo[0]"
And IV-OPT does not realize that it is just a loop from 0 to 1 (but that might be because of fold not 
folding what is about).

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |17640
           Severity|normal                      |enhancement
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
           Keywords|                            |missed-optimization
   Last reconfirmed|0000-00-00 00:00:00         |2005-01-26 13:57:32
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

[rguenth at tat dot physik dot uni-tuebingen dot de]

------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de  2005-01-26 14:10 -------
We can also not fold &i[0] == &i[1] to false in

int foo(void)
{
        int i[2];
        if (&i[0] == &i[1])
                return 1;
        return 0;
}

or i+0 == i+1 which is transformed to &i[0] == &i[1].

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-26 14:17 -------
(In reply to comment #2)
> We can also not fold &i[0] == &i[1] to false in
I filed PR 19641 for that.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |19641


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-26 14:19 -------
(In reply to comment #3)
> (In reply to comment #2)
> > We can also not fold &i[0] == &i[1] to false in
> I filed PR 19641 for that.
Actually I had already file PR 15791 for that.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |15791


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

[rguenth at tat dot physik dot uni-tuebingen dot de]

------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de  2005-01-28 14:21 -------
Folding &x.foo[2] == &x.foo to false does not help the testcase, as fold
never sees this comparison.  Instead the initial code the C++ frontend
creates for ctor and dtor of arrays contains temporaries for these already.
It seems the C++ frontend tries to be clever here, creating pointer IVs for
the loop and doing too much manual optimizing.

What other pass than fold() is supposed to handle this sort of simplification?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

[pinskia at gcc dot gnu dot org]

-- 
Bug 19639 depends on bug 15791, which changed state.

Bug 15791 Summary: fold misses that two ADDR_EXPR of an arrary obvious not equal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15791

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 20:48 -------
(In reply to comment #5)
> What other pass than fold() is supposed to handle this sort of simplification?
Actually if you look at the tree dumps you will see that we removed that if.  It does not help the testcase 
as we already removed that if on the rtl level.  But now the only problem is removing empty loops.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

[rguenth at tat dot physik dot uni-tuebingen dot de]

------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de  2005-01-29 21:14 -------
Or we could simply unroll the loop completely, but while SCEV finds
the IV as

(set_scalar_evolution
  (scalar = this_6)
  (scalar_evolution = {(struct Foo * const) &x.foo[2] - 4B, +, -4B}_1))
)

it does not know about the number of iterations:

(set_nb_iterations_in_loop = scev_not_known))

  # BLOCK 1 
  # PRED: 3 [100.0%]  (fallthru) 0 [100.0%]  (fallthru,exec)
Invalid sum of incoming frequencies 10258, should be 10000
  # thisD.1628_1 = PHI <thisD.1628_6(3), &xD.1600.fooD.1587[2](0)>;
<L2>:;
  thisD.1628_6 = thisD.1628_1 - 4;
  if (thisD.1628_6 == &xD.1600.fooD.1587) goto <L6>; else goto <L10>;
  # SUCC: 2 [11.0%]  (loop_exit,true,exec) 3 [89.0%]  (dfs_back,false,exec)
  
  # BLOCK 3 
  # PRED: 1 [89.0%]  (dfs_back,false,exec)
<L10>:;
  goto <bb 1> (<L2>); 
  # SUCC: 1 [100.0%]  (fallthru)

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 21:19 -------
As(In reply to comment #7)
> Or we could simply unroll the loop completely, but while SCEV finds
> the IV as

Again this is most likely because fold does not fold "&x.foo[2] - 4B" to "&x.foo[0]", or someone forgets 
to call fold on that.  I know that fold_stmt can do it.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

[rguenth at tat dot physik dot uni-tuebingen dot de]

------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de  2005-01-30 18:54 -------
Subject: Re:  Funny (horrible) code for empty
 destructor

pinskia at gcc dot gnu dot org wrote:
> ------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 21:19 -------
> As(In reply to comment #7)
> 
>>Or we could simply unroll the loop completely, but while SCEV finds
>>the IV as
> 
> 
> Again this is most likely because fold does not fold "&x.foo[2] - 4B" to "&x.foo[0]", or someone forgets 
> to call fold on that.  I know that fold_stmt can do it.

Yeah, I can find code to fold &x.foo[i] - c * j, but not without the c * 
mult.  I'll look into this later.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

[rguenth at gcc dot gnu dot org]

------- Additional Comments From rguenth at gcc dot gnu dot org  2005-02-07 14:43 -------
The missed folding of &x.foo[2] - 4B is again due to different representation
of array refs for C and C++.  A C testcase is folded, a C++ not.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

[rguenth at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |19807


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

[rguenth at gcc dot gnu dot org]

------- Additional Comments From rguenth at gcc dot gnu dot org  2005-02-07 17:22 -------
Split that missed &x.foo[2] - 4B folding out to PR19807.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|19807                       |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

[rguenth at gcc dot gnu dot org]

------- Additional Comments From rguenth at gcc dot gnu dot org  2005-02-07 17:25 -------
It seems the new (and old?) bugzilla doesn't check up-to-date-ness of the bug
wrt changes of just "depends on".  Re-added 19807.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |19807


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

[rguenth at gcc dot gnu dot org]

------- Additional Comments From rguenth at gcc dot gnu dot org  2005-02-16 09:52 -------
With PR15791 fixed we now create at -O2

void foo() ()
{
  struct Foo * const this.6;
  struct Foo * D.1654;
  struct Foo * const this;
  register struct Foo * D.1634;
  struct Foo[2] * D.1633;
  struct NonPod x;

<bb 0>:
  this = &x.foo[2];

<L2>:;
  this = this - 4;
  D.1654 = 0B;
  if (D.1654 + this == &x.foo) goto <L6>; else goto <L2>;

<L6>:;
  return;
}

With PR19807 fixed (patch in testing) we're down to

void foo() ()
{
  unsigned int ivtmp.1;
  struct Foo * pretmp.0;
  struct Foo * const this;
  register struct Foo * D.1634;
  struct Foo[2] * D.1633;
  struct NonPod x;

<bb 0>:
  ivtmp.1 = 2;

<L2>:;
  ivtmp.1 = ivtmp.1 - 1;
  if (ivtmp.1 == 0) goto <L6>; else goto <L2>;

<L6>:;
  return;
}

which is PR17640 and the tree-unroller will happily unroll and optimize
to an empty function (before fixing PR19807 it wouldn't do that).

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-25 14:51 -------
Patch posted here: <http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02592.html>.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://gcc.gnu.org/ml/gcc-
                   |                            |patches/2005-
                   |                            |04/msg02592.html
           Keywords|                            |patch


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-07 19:09 -------
On the mainline I get:
void foo() ()
{
  void * ivtmp.3;
  struct NonPod x;

<bb 0>:
  ivtmp.3 = &x.foo[2];

<L2>:;
  ivtmp.3 = ivtmp.3 - 4B;
  if (ivtmp.3 == &x.foo) goto <L6>; else goto <L2>;

<L6>:;
  return;

}

Which is still not good as we could do :(.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2005-01-26 13:57:32         |2005-05-07 19:09:02
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-11 08:15 -------
Subject: Bug 19639

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	rguenth@gcc.gnu.org	2005-05-11 08:14:45

Modified files:
	gcc            : ChangeLog fold-const.c tree-ssa-propagate.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/g++.dg/tree-ssa: pr19807.C 

Log message:
	2005-05-11  Richard Guenther  <rguenth@gcc.gnu.org>
	
	PR middle-end/19807
	PR tree-optimization/19639
	* fold-const.c (try_move_mult_to_index): Handle INTEGER_CST
	and generic summands for char* as s * delta, too, folding &a[i]
	CODE x to &a[i CODE x/s].  Use tree_int_cst_equal
	for comparison of steps.  Convert types for index addition.
	(fold_binary): Adjust the callers to always dispatch to
	try_move_mult_to_index.
	* tree-ssa-propagate.c (set_rhs): Avoid setting rhs to
	expr with non-gimple ARRAY_REF offset.
	
	* g++.dg/tree-ssa/pr19807.C: New testcase.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8725&r2=2.8726
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&r1=1.576&r2=1.577
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-propagate.c.diff?cvsroot=gcc&r1=2.18&r2=2.19
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5463&r2=1.5464
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/tree-ssa/pr19807.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

[rguenth at gcc dot gnu dot org]

-- 
Bug 19639 depends on bug 19807, which changed state.

Bug 19807 Summary: fold does not fold &a[4]-1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19807

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

[rguenth at gcc dot gnu dot org]

------- Additional Comments From rguenth at gcc dot gnu dot org  2005-05-11 09:14 -------
With optimization we now get

void foo() ()
{
  unsigned int ivtmp.0;
  struct Foo * const this;
  register struct Foo * D.1740;
  struct Foo[2] * D.1739;
  struct NonPod x;

<bb 0>:

<L6>:;
  return;

}

aka fixed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.1.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

[pinskia at gcc dot gnu dot org]

-- 
Bug 19639 depends on bug 17640, which changed state.

Bug 17640 Summary: empty loop not removed after optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17640

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
             Status|ASSIGNED                    |NEW
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639