[Bug c++/56894] New: performance regression in gcc 4.7.x due to a += operation

[Bug c++/56894] New: performance regression in gcc 4.7.x due to a += operation

[laurent.alfonsi at st dot com]

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

             Bug #: 56894
           Summary: performance regression in gcc 4.7.x due to a +=
                    operation
    Classification: Unclassified
           Product: gcc
           Version: 4.7.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: laurent.alfonsi@st.com


Hello,

I have identified a big performance regression between 4.6 and 4.7. (I have
enclosed the pathological test).

After investigation, it is because of the += statement applied on 2 signed
chars.
  - It is now type-promoted to "int" when it is written "result += foo()".   
(since 4.7)
  - it is type promoted to "unsigned char" when it is written "result = result
+ foo()".

The "char->int->char" cast is blocking the sccp constant propagation
optimization.

More precisely, in gcc 4.6, the "result" variable is seen as a loop_invariant
(no_evolution_in_loop_p):
 <nop_expr 0xf7fbb8a4
    type <integer_type 0xf7ee4180 char sizes-gimplified public string-flag
type_6 QI [...]>
    arg 0 <polynomial_chrec 0xf7fb96e4
        type <integer_type 0xf7ee4120 unsigned char public unsigned string-flag
QI [...]>
        arg 0 <integer_cst 0xf7eccac0 constant 2>
        arg 1 <integer_cst 0xf7ecc120 constant 0>
        arg 2 <integer_cst 0xf7f88e20 constant 1>>>

In gcc 4.7, the result variable is not seen as a loop_invariant due to the cast
to int:
    type <integer_type 0xf7de32a0 char sizes-gimplified public string-flag
type_6 QI[...]>
    arg 0 <polynomial_chrec 0xf7ecd180
        type <integer_type 0xf7de33c0 int sizes-gimplified public type_6
SI[...]>       
        arg 0 <integer_cst 0xf7dcbe70 constant 2>
        arg 1 <integer_cst 0xf7dcba80 constant 0>
        arg 2 <integer_cst 0xf7dcba9c constant 1>>>

I don't know how to change the chrec detection to recover the constant
propagation in gcc 4.7.

Thanks,
Laurent

[Bug c++/56894] performance regression in gcc 4.7.x due to a += operation

[laurent.alfonsi at st dot com]

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

--- Comment #1 from Laurent Aflonsi <laurent.alfonsi at st dot com> 2013-04-09 15:23:16 UTC ---
Created attachment 29842
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29842
testcase to reproduce

[Bug c++/56894] performance regression in gcc 4.7.x due to a += operation

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> 2013-04-10 08:11:36 UTC ---
The regression was fixed for 4.8 with

2012-06-27  Richard Guenther  <rguenther@suse.de>

        PR middle-end/53676
        * tree-chrec.c (chrec_convert_1): Represent truncation to
        a type with undefined overflow as truncation to an unsigned
        type converted to the type with undefined overflow.
        * tree-scalar-evolution.c (interpret_rhs_expr): For computing
        the scalar evolution of a truncated widened operation avoid
        looking at the non-existing evolution of the widened operation
        result.

which this bug is a duplicate of.

*** This bug has been marked as a duplicate of bug 53676 ***