[Bug rtl-optimization/31849] New: Code size regression caused by fix to PR 31360

[Bug rtl-optimization/31849] New: Code size regression caused by fix to PR 31360

[rearnsha at gcc dot gnu dot org]

The fix to PR31360 has caused significant code size regressions on ARM-EABI. 
An example of this is from zlib (adler32.c) and is attached, compile with -Os
-mcpu=arm7tdmi -fno-short-enums -w 

The new code:
1) Hoists a register containing 0 out of the loop
2) Uses that *only* as a copy into another register (mov reg, #0 costs exactly
the same as mov reg, reg)
3) By doing the above, somehow prevents the post-increment sequence from being
found.
4) Forces another register to be saved by the function.


-- 
           Summary: Code size regression caused by fix to PR 31360
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rearnsha at gcc dot gnu dot org
GCC target triplet: arm-none-eabi


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

[Bug rtl-optimization/31849] Code size regression caused by fix to PR 31360

[rearnsha at gcc dot gnu dot org]

------- Comment #1 from rearnsha at gcc dot gnu dot org  2007-05-07 01:06 -------
Created an attachment (id=13520)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13520&action=view)
source code showing regression

compiled code for this file regresses by approximately 3%


-- 


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

[Bug rtl-optimization/31849] Code size regression caused by fix to PR 31360

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2007-05-07 02:36 -------
> 1) Hoists a register containing 0 out of the loop
The correct thing to do.
>2) Uses that *only* as a copy into another register (mov reg, #0 costs exactly
the same as mov reg, reg)
Interesting, but this is also true on ppc where I reported the original
problem.

> 3) By doing the above, somehow prevents the post-increment sequence from being
found.
This might be the true issue.  But is this a regression from 4.1 where loop.c
would actually move this invariant?


-- 


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

[Bug rtl-optimization/31849] [4.2/4.3 Regression] Code size regression caused by fix to PR 31360

[steven at gcc dot gnu dot org]

------- Comment #3 from steven at gcc dot gnu dot org  2007-05-07 04:14 -------
Yup.  So the heuristic to just move everything out of the loop needs another
tweak.  This is sort-of the reverse of the problem for Bug 31360.

Adding Mark to put this bug on his radar.


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark at codesourcery dot com
  BugsThisDependsOn|                            |31360
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-05-07 04:14:13
               date|                            |
            Summary|Code size regression caused |[4.2/4.3 Regression] Code
                   |by fix to PR 31360          |size regression caused by
                   |                            |fix to PR 31360


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

[Bug rtl-optimization/31849] [4.2/4.3 Regression] Code size regression caused by fix to PR 31360

[rearnsha at gcc dot gnu dot org]

------- Comment #4 from rearnsha at gcc dot gnu dot org  2007-05-07 09:34 -------
(In reply to comment #2)
> > 1) Hoists a register containing 0 out of the loop
> The correct thing to do.
>
Not necessarily.  Hoisting literal constants means that opportunities to simply
insns based on that constant are potentially lost.


-- 


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

[Bug rtl-optimization/31849] [4.2/4.3 Regression] Code size regression caused by fix to PR 31360

[rakdver at kam dot mff dot cuni dot cz]

------- Comment #5 from rakdver at kam dot mff dot cuni dot cz  2007-05-07 09:38 -------
Subject: Re:  [4.2/4.3 Regression] Code size regression caused by fix to PR
31360

> (In reply to comment #2)
> > > 1) Hoists a register containing 0 out of the loop
> > The correct thing to do.
> >
> Not necessarily.  Hoisting literal constants means that opportunities to simply
> insns based on that constant are potentially lost.

This could be prevented if invariant motion added equivalence notes;
nevertheless,
one could argue that such simplifications should have been performed
before loop invariant motion (in cse).


-- 


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

[Bug rtl-optimization/31849] [4.2/4.3 Regression] Code size regression caused by fix to PR 31360

[stevenb dot gcc at gmail dot com]

------- Comment #6 from stevenb dot gcc at gmail dot com  2007-05-07 09:46 -------
Subject: Re:  [4.2/4.3 Regression] Code size regression caused by fix to PR
31360

Constant / copy simplifications should be done in at least CSE,
fwprop, and the gcse CPROP passes (we run CPROP three times!).


-- 


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

[Bug rtl-optimization/31849] [4.2/4.3 Regression] Code size regression caused by fix to PR 31360

[rearnsha at gcc dot gnu dot org]

------- Comment #7 from rearnsha at gcc dot gnu dot org  2007-05-07 10:43 -------
Here's another example of code that is now significantly worse (~20% larger). 
Rather than incrementing the base pointers on each iteration of the loop, we
now maintain both base pointers and and offset.  This costs two extra registers
for no benefit at all.

char * strncat(char *dest, const char *src, unsigned count)
{
        char *tmp = dest;

        if (count) {
                while (*dest)
                        dest++;
                while ((*dest++ = *src++)) {
                        if (--count == 0) {
                                *dest = '\0';
                                break;
                        }
                }
        }

        return tmp;
}


-- 


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

[Bug rtl-optimization/31849] [4.2/4.3 Regression] Code size regression caused by fix to PR 31360

[rakdver at gcc dot gnu dot org]

------- Comment #8 from rakdver at gcc dot gnu dot org  2007-05-07 11:22 -------
(In reply to comment #7)
> Here's another example of code that is now significantly worse (~20% larger). 
> Rather than incrementing the base pointers on each iteration of the loop, we
> now maintain both base pointers and and offset.  This costs two extra registers
> for no benefit at all.

actually, this should save one addition (only the index is incremented, the
additions of index to bases are done in the addressing mode).  Since we do not
run out of registers, this seems to be the correct thing to do.

However, for some reason we do not currently eliminate the use of the final
value of dest (which should be replaced by base_of_dest + count).


-- 


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

[Bug rtl-optimization/31849] [4.2/4.3 Regression] Code size regression caused by fix to PR 31360

[rearnsha at gcc dot gnu dot org]

------- Comment #9 from rearnsha at gcc dot gnu dot org  2007-05-07 13:50 -------
(In reply to comment #8)
>
> actually, this should save one addition (only the index is incremented, the
> additions of index to bases are done in the addressing mode).  

When a machine has a post-increment instruction (as ARM does) the addition is
free.  So really there should be no additions in this code (though the previous
version had one, to the current two).


-- 


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

[Bug rtl-optimization/31849] [4.2/4.3 Regression] Code size regression caused by fix to PR 31360

[pinskia at gcc dot gnu dot org]

------- Comment #10 from pinskia at gcc dot gnu dot org  2007-05-07 13:57 -------
So this comes down to the orders of passes?  At least that is what is being
said as far as I can tell (though maybe flow is just too stupid to pull back
the increment and have it as being free).


-- 


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

[Bug rtl-optimization/31849] [4.2/4.3 Regression] Code size regression caused by fix to PR 31360

[rakdver at gcc dot gnu dot org]

------- Comment #11 from rakdver at gcc dot gnu dot org  2007-05-07 14:25 -------
(In reply to comment #10)
> So this comes down to the orders of passes?  At least that is what is being
> said as far as I can tell (though maybe flow is just too stupid to pull back
> the increment and have it as being free).

About what testcase are you speaking?  As for the first one, I really have no
idea yet what is going on there (all that was written here are just
hypothesis).

As for the second one, the problem is that ivopts do not know about
autoincrements, so it transforms

  something (*src++);
  something (*dest++);
(which is better on autoinc-having architecture)

to

  something (src[i]);
  something (dest[i]);
  i++;

(which would be better if autoinc is not available).

At the moment, I have no intention to teach ivopts about autoinc (since ivopts
need to be rewritten, anyway).


-- 


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

[Bug rtl-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
   Target Milestone|---                         |4.3.0


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

[Bug rtl-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[rakdver at gcc dot gnu dot org]

------- Comment #18 from rakdver at gcc dot gnu dot org  2007-07-04 13:32 -------
(In reply to comment #0)
> The fix to PR31360 has caused significant code size regressions on ARM-EABI. 
> An example of this is from zlib (adler32.c) and is attached, compile with -Os
> -mcpu=arm7tdmi -fno-short-enums -w 
> 
> The new code:
> 1) Hoists a register containing 0 out of the loop
> 2) Uses that *only* as a copy into another register (mov reg, #0 costs exactly
> the same as mov reg, reg)

Actually, rtx_cost claims that mov reg, #0 costs 20, while mov reg, reg costs
16.  Fixing this (assuming that is indeed wrong) will not fix the problem
(without further changes to the invariant motion), but it is the first step.


-- 


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

[Bug rtl-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2


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

[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[ebotcazou at gcc dot gnu dot org]

------- Comment #19 from ebotcazou at gcc dot gnu dot org  2007-11-24 18:43 -------
The pessizimation actually happens at the tree level, -fivopts turns

<bb 9>:
  s1 = (long unsigned int) *buf + s1;
  buf = buf + 1;
  s2 = s1 + s2;
  k = k + -1;
  if (k != 0)
    goto <bb 9>;
  else
    goto <bb 10>;

into

<bb 10>:
  s1 = s1 + (long unsigned int) MEM[base: buf.91, index: D.1322];
  s2 = s1 + s2;
  D.1322 = D.1322 + 1;
  if (D.1322 != (unsigned int) k)
    goto <bb 10>;
  else
    goto <bb 11>;

in final_cleanup.


Couldn't ivopts be taught to recognize "dec and branch on zero" patterns

  k_114 = k_15 + -1;
  if (k_114 != 0)
    goto <bb 10>;
  else
    goto <bb 11>;

and take into account their breakage for its cost estimates somehow?


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu dot
                   |                            |org
          Component|rtl-optimization            |tree-optimization


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

[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[rakdver at gcc dot gnu dot org]

------- Comment #20 from rakdver at gcc dot gnu dot org  2007-11-24 19:08 -------

> Couldn't ivopts be taught to recognize "dec and branch on zero" patterns
> 
>   k_114 = k_15 + -1;
>   if (k_114 != 0)
>     goto <bb 10>;
>   else
>     goto <bb 11>;
> 
> and take into account their breakage for its cost estimates somehow?

Why?  If using dec and branch is profitable, doloop pass should do it; the
transformation that ivopts do does not prevent that or make it any more
difficult.


-- 


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

[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[ebotcazou at gcc dot gnu dot org]

------- Comment #21 from ebotcazou at gcc dot gnu dot org  2007-11-24 19:19 -------
> Why?  If using dec and branch is profitable, doloop pass should do it; the
> transformation that ivopts do does not prevent that or make it any more
> difficult.

I'm not sure that blindly doing transformations in the hope that subsequent
ones will repair the potential damages is always the way to go.  Why not
avoid causing the damages in some cases?  Is that really too "old-style"?


-- 


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

[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[rakdver at kam dot mff dot cuni dot cz]

------- Comment #22 from rakdver at kam dot mff dot cuni dot cz  2007-11-24 21:52 -------
Subject: Re:  [4.3 Regression] Code size regression caused by fix to PR 31360

> > Why?  If using dec and branch is profitable, doloop pass should do it; the
> > transformation that ivopts do does not prevent that or make it any more
> > difficult.
> 
> I'm not sure that blindly doing transformations in the hope that subsequent
> ones will repair the potential damages is always the way to go.  Why not
> avoid causing the damages in some cases?  Is that really too "old-style"?

Ivopts cannot create decrease-and-branch instruction by itself, as it is
run on trees.  So we have to rely on doloop to do so.  For doloop, the
exact shape of the exit test does not matter, so whether ivopts will do
the transformation or not is completely irrelevant.

So, while altering the cost function of ivopts to take decrease-and-branch
patterns into account and preserving the decreasing induction variable
would not be too hard (although it is a bit dubious whether it would
also be wise), I do not see how that would help.


-- 


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

[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[rakdver at gcc dot gnu dot org]

------- Comment #23 from rakdver at gcc dot gnu dot org  2007-11-24 21:56 -------
Let me have a look what's going on here.


-- 

rakdver at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rakdver at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2007-05-07 04:14:13         |2007-11-24 21:56:11
               date|                            |


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

[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[rakdver at gcc dot gnu dot org]

------- Comment #24 from rakdver at gcc dot gnu dot org  2007-11-24 22:28 -------
(In reply to comment #20)
> > Couldn't ivopts be taught to recognize "dec and branch on zero" patterns
> > 
> >   k_114 = k_15 + -1;
> >   if (k_114 != 0)
> >     goto <bb 10>;
> >   else
> >     goto <bb 11>;
> > 
> > and take into account their breakage for its cost estimates somehow?
> 
> Why?  If using dec and branch is profitable, doloop pass should do it; the
> transformation that ivopts do does not prevent that or make it any more
> difficult.

sorry, I misunderstood what you are asking for.  Yes, ivopts would have to
solve this; however, they would not only have to know about the possibility to
compare with zero and jump in one instruction, but also about autoincrement
addressing modes, to get this one correctly.  That looks like a bit complicated
way to solve the issue, I need to think about it more.


-- 


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

[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[rakdver at gcc dot gnu dot org]

------- Comment #25 from rakdver at gcc dot gnu dot org  2007-11-26 00:48 -------
Created an attachment (id=14637)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14637&action=view)
Patch to make ivopts take autoincrement addressing modes into account

Ivopts take autoincrement addressing modes into account with this patch (in a
fairly simplistic form, sufficient to improve the code for the testcases in
this PR).  However, I do not have access to any architecture where I could test
it (I somewhat suspect it might cause performance regressions -- using
autoincrement addressing modes is not necessarily always profitable).


-- 


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

[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[rakdver at gcc dot gnu dot org]

-- 

rakdver at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|rakdver at gcc dot gnu dot  |unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


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

[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[mmitchel at gcc dot gnu dot org]

------- Comment #26 from mmitchel at gcc dot gnu dot org  2007-11-26 00:53 -------
Zdenek, do you have the ability to get code-size measurements on ARM?  (You
don't need to actually run the code to find out if this improves code density.)
 If you don't, I'll ask someone at CodeSourcery to measure that.

Thanks,

-- Mark


-- 


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

[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[rakdver at kam dot mff dot cuni dot cz]

------- Comment #27 from rakdver at kam dot mff dot cuni dot cz  2007-11-26 01:12 -------
Subject: Re:  [4.3 Regression] Code size regression caused by fix to PR 31360

> Zdenek, do you have the ability to get code-size measurements on ARM?  (You
> don't need to actually run the code to find out if this improves code density.)
>  If you don't, I'll ask someone at CodeSourcery to measure that.

I can check the code size; however, I am somewhat concerned about
possible performance regressions on other architectures,
in particular, ia64, where the dependences created by introducing
autoincrements might conflict with scheduling.  I would appreciate
if someone could run some benchmark on ia64 with the patch.


-- 


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

[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[pinskia at gcc dot gnu dot org]

------- Comment #28 from pinskia at gcc dot gnu dot org  2007-11-26 01:24 -------
A couple of comments about the patch.
+ #define CP_AUTOINC_OFFSET(CP) ((int) (size_t) (CP)->value)

I don't like this idea at all.

The patch should support pre increment also (this shows up on PPC) and pre/post
decrement.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization


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

[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[rakdver at kam dot mff dot cuni dot cz]

------- Comment #29 from rakdver at kam dot mff dot cuni dot cz  2007-11-26 01:42 -------
Subject: Re:  [4.3 Regression] Code size regression caused by fix to PR 31360

> ------- Comment #28 from pinskia at gcc dot gnu dot org  2007-11-26 01:24 -------
> A couple of comments about the patch.
> + #define CP_AUTOINC_OFFSET(CP) ((int) (size_t) (CP)->value)
> 
> I don't like this idea at all.

I may change cost_pair to union, if this bothers you too much.

> The patch should support pre increment also (this shows up on PPC) and pre/post
> decrement.

post-decrement is already supported.  Pre-(inc/dec)rements are more
complicated, as supporting them would require us to create induction
variables incremented at the start of the loop body (instead of at the
end, as we do now).


-- 


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

[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[rakdver at gcc dot gnu dot org]

------- Comment #30 from rakdver at gcc dot gnu dot org  2007-11-26 05:08 -------
The patch improves size of adler32 (and several other files in zlib) by about
2%.  However, overall on the whole csibe it is neutral (the sum of the sizes of
all the files increases by 0.02%) -- the changes in size of the files range
from 7.5% improvement to 7% regression.  I did not investigate the cause of the
regressions yet.


-- 


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

[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[steven at gcc dot gnu dot org]

------- Comment #31 from steven at gcc dot gnu dot org  2007-11-26 09:05 -------
I experimented with autoinc/-dec addressing modes for ARM earlier this year and
also saw smaller code size reductions (just over 2% overall on CSiBE).  Looks
like an area worth working on :-)

Apparently this bug has to do with code size, so let't make it block bug 16996.


-- 


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

[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[steven at gcc dot gnu dot org]

------- Comment #32 from steven at gcc dot gnu dot org  2008-01-27 15:35 -------
I have re-tested Zdenek's patch on arm-unknown-elf.

128 files are smaller with the patch, and 126 files are larger.  The total size
increase with the patch is 324 bytes on 3601910 bytes total size (or <0.01%)
with r131735.  Neglecting all size increases, the total win with the patch is
-2552 bytes, which is still less than one tenth of a percent.

The biggest win is for lib/zlib_inflate/inffast from the package
linux-2.4.23-pre3-testplatform.  The size decrease is 112 bytes with the patch,
or -9.84%.

The biggest loser is jidctred from jpeg-6b with 100 bytes for +7.08%, but in
bytes the loser is src/nrrd/axis from teem-1.6.0-src with 184 bytes or 4.05%.

It would be interesting to investigate the inffast improvement.  But the
overall gain or loss with this patch makes it seem this isn't worth perusing
too much further.


-- 


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

[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[alexandre dot nunes at gmail dot com]

------- Comment #33 from alexandre dot nunes at gmail dot com  2008-02-12 00:32 -------
I compiled gcc 4.3 for arm-unknown-elf (today's trunk, not sure about the rev).
Compiling three in three firmware images gave me size regressions with -Os;
with -O2, gcc 4.3 produces smaller code than 4.2.3:

# Increased about 3.1%
#nam gcc v  fl code size
img1 4.2.3 -Os 4786
img1 4.3.- -Os 4936


# Increased about 1.3%
img2 4.2.3 -Os 3372
img2 4.3.- -Os 3416


# Decreased (!) about 3,3%
img3 4.2.3 -O2  13892
img3 4.3.- -O2  13436

# Increased about 4,4%
img3 4.2.3 -Os  12348
img3 4.3.0 -Os  12892


-- 

alexandre dot nunes at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alexandre dot nunes at gmail
                   |                            |dot com


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

[Bug tree-optimization/31849] [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)

[rguenth at gcc dot gnu dot org]

------- Comment #34 from rguenth at gcc dot gnu dot org  2008-03-14 16:47 -------
Adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |4.3.0
   Target Milestone|4.3.0                       |4.3.1


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

[Bug tree-optimization/31849] [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)

[hp at gcc dot gnu dot org]

------- Comment #35 from hp at gcc dot gnu dot org  2008-05-23 23:36 -------
Looks like this is the new-generation/df equivalent of PR20211!


-- 


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

[Bug tree-optimization/31849] [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)

[rguenth at gcc dot gnu dot org]

------- Comment #36 from rguenth at gcc dot gnu dot org  2008-06-06 14:56 -------
4.3.1 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.1                       |4.3.2


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

[Bug tree-optimization/31849] [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)

[pinskia at gcc dot gnu dot org]

------- Comment #37 from pinskia at gcc dot gnu dot org  2008-06-13 14:34 -------
*** Bug 36135 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gunnar at greyhound-data dot
                   |                            |com


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

[Bug tree-optimization/31849] [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)

[joel at gcc dot gnu dot org]

------- Comment #38 from joel at gcc dot gnu dot org  2008-07-15 19:33 -------
Created an attachment (id=15914)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15914&action=view)
Zoltan's test case


-- 


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

[Bug tree-optimization/31849] [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)

[joel at gcc dot gnu dot org]

------- Comment #39 from joel at gcc dot gnu dot org  2008-07-15 19:36 -------
I compiled Zoltan's example test.c for the various arm-rtems gcc versions I had
laying around.  The GCC version string is modified to reflect the RTEMS
specific patch revision and newlib version used in the binary.  I used -Os,
-O1, and -O3.  Here is the report.  

arm-rtems-gcc (GCC) 3.2.3 (OAR Corporation
gcc-3.2.3-20040420/newlib-1.11.0-20030605-4)
===> -Os 1020 0 0 1020 3fc test.o
===> -O1 1024 0 0 1024 400 test.o
===> -O2 1024 0 0 1024 400 test.o
arm-rtems4.7-gcc (GCC) 4.1.1 (RTEMS gcc-4.1.1/newlib-1.15.0-12.fc8)
===> -Os 936 0 0 936 3a8 test.o
===> -O1 840 0 0 840 348 test.o
===> -O2 892 0 0 892 37c test.o
arm-rtems4.8-gcc (GCC) 4.2.4 (RTEMS gcc-4.2.4/newlib-1.15.0-30.fc8)
===> -Os 928 0 0 928 3a0 test.o
===> -O1 852 0 0 852 354 test.o
===> -O2 908 0 0 908 38c test.o
arm-rtems4.9-gcc (GCC) 4.3.1
===> -Os 1740 0 0 1740 6cc test.o
===> -O1 868 0 0 868 364 test.o
===> -O2 1944 0 0 1944 798 test.o


-- 


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

[Bug tree-optimization/31849] [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)

[jsm28 at gcc dot gnu dot org]

------- Comment #40 from jsm28 at gcc dot gnu dot org  2008-08-27 22:01 -------
4.3.2 is released, changing milestones to 4.3.3.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.2                       |4.3.3


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

[Bug tree-optimization/31849] [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)

[amylaar at gcc dot gnu dot org]

------- Comment #41 from amylaar at gcc dot gnu dot org  2008-10-22 13:16 -------
(In reply to comment #0)

> 1) Hoists a register containing 0 out of the loop

Does the TARGET_RTX_COSTS set the cost to zero for the constant zero?



-- 

amylaar at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amylaar at gcc dot gnu dot
                   |                            |org


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

[Bug tree-optimization/31849] [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)

[amylaar at gcc dot gnu dot org]

------- Comment #42 from amylaar at gcc dot gnu dot org  2008-12-10 04:29 -------
(In reply to comment #25)
> Created an attachment (id=14637)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14637&action=view) [edit]
> Patch to make ivopts take autoincrement addressing modes into account
> 
> Ivopts take autoincrement addressing modes into account with this patch (in a
> fairly simplistic form, sufficient to improve the code for the testcases in
> this PR).  However, I do not have access to any architecture where I could test
> it (I somewhat suspect it might cause performance regressions -- using
> autoincrement addressing modes is not necessarily always profitable).
> 

AFAICS this does not take any AUTO_INC modes but POST_INC into account.
When you have PRE_MODIFY and POST_MODIFY, most or all iv increments become
free if there is a memory access using them.

Also, if you are not sure yet of the merit of the patch, it would be best to
make its effect an option, so that it can be easily benchmarked.
And if it turns out to be good for some targets but bad for others, we can keep
it an option which gets defaulted appropriately by OPTIMIZATION_OPTIONS.


-- 


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

[Bug tree-optimization/31849] [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)

[amylaar at gcc dot gnu dot org]

------- Comment #43 from amylaar at gcc dot gnu dot org  2008-12-10 05:29 -------
(In reply to comment #25)
> Created an attachment (id=14637)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14637&action=view) [edit]
> Patch to make ivopts take autoincrement addressing modes into account
> 
> Ivopts take autoincrement addressing modes into account with this patch (in a
> fairly simplistic form, sufficient to improve the code for the testcases in
> this PR).  However, I do not have access to any architecture where I could test
> it (I somewhat suspect it might cause performance regressions -- using
> autoincrement addressing modes is not necessarily always profitable).
> 

You patch suffered from some bitrot.  After fixing the merge issues, I can
confirm that it fixes the bcmp regression problem for ARC (see PR38440).


-- 


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

[Bug tree-optimization/31849] [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)

[stevenb dot gcc at gmail dot com]

------- Comment #44 from stevenb dot gcc at gmail dot com  2008-12-10 22:30 -------
Subject: Re:  [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts
not understanding autoincrement)

Joern, can you attach the updated patch?


-- 


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

[Bug tree-optimization/31849] [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)

[amylaar at gcc dot gnu dot org]

------- Comment #45 from amylaar at gcc dot gnu dot org  2008-12-11 02:07 -------
(In reply to comment #44)
> Subject: Re:  [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts
> not understanding autoincrement)
> 
> Joern, can you attach the updated patch?

I still wait for confirmation from the FSF that our Copyright assignment has
been filed.

In the meantime, I'll send you the patch by personal email.


-- 


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

[Bug tree-optimization/31849] [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)

[rguenth at gcc dot gnu dot org]

------- Comment #46 from rguenth at gcc dot gnu dot org  2009-01-24 10:19 -------
GCC 4.3.3 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.3                       |4.3.4


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

[Bug tree-optimization/31849] [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)

[alexandre dot nunes at gmail dot com]

------- Comment #47 from alexandre dot nunes at gmail dot com  2009-03-06 15:29 -------
Any news on the subject?


-- 


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

[Bug tree-optimization/31849] [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)

[amylaar at gcc dot gnu dot org]

------- Comment #48 from amylaar at gcc dot gnu dot org  2009-03-06 15:54 -------
Created an attachment (id=17408)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17408&action=view)
patch to take POST_DEC and POST_MODIFY into account

The Copyright assignment issue has been resulved now.

This is the patch I've sent to Steven Bosscher in December.
It would be good if we had some benchmarks on different architectures
to check the merit of having the f{,no-}ivopts-post-inc and
f{,no-}ivopts-post-modify options.


-- 


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

[Bug tree-optimization/31849] [4.3/4.4/4.5 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)

[rguenth at gcc dot gnu dot org]

------- Comment #49 from rguenth at gcc dot gnu dot org  2009-08-04 12:28 -------
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.4                       |4.3.5


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

[Bug tree-optimization/31849] [4.3/4.4/4.5 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)

[steven at gcc dot gnu dot org]

------- Comment #50 from steven at gcc dot gnu dot org  2010-02-04 16:04 -------
Bernd Schmidt has worked on this, see here:

http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01788.html
http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00268.html

It is hard to tell whether this has actually addresses the issues raised in
this bug report, because it is unclear what code the OP is expecting from the
compiler.


-- 


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

[Bug tree-optimization/31849] [4.3/4.4/4.5 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)

[steven at gcc dot gnu dot org]

------- Comment #51 from steven at gcc dot gnu dot org  2010-02-10 10:42 -------
Could the OP be so kind to see if this is still a problem? And, if this is
still a problem with an unpatched compiler: whether the problem goes away if
arm_arm_address_cost() returns 1 unconditionally (so that this bug can be
re-qualified as a target problem rather than a tree-optimization issue)?


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


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

[Bug tree-optimization/31849] [4.3/4.4/4.5/4.6 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)

[rguenth at gcc dot gnu dot org]

------- Comment #52 from rguenth at gcc dot gnu dot org  2010-05-22 18:11 -------
GCC 4.3.5 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.5                       |4.3.6


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

[Bug tree-optimization/31849] [4.3/4.4/4.5/4.6 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)

[steven at gcc dot gnu dot org]

------- Comment #53 from steven at gcc dot gnu dot org  2010-07-20 22:12 -------
Could the OP be so kind to see if this is still a problem?


-- 


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