[Bug target/50176] New: [4.6/4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[Bug target/50176] New: [4.6/4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[izamyatin at gmail dot com]

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

             Bug #: 50176
           Summary: [4.6/4.7 Regression] 4.7 generates spill-fill dealing
                    with char->int conversion
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: izamyatin@gmail.com


Created attachment 25088
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25088
testcase for the problem

I observe that for attached testcase (made from one of tests from EEMBC 2.0
suite) 4.7 generates spill-fill pair when (I suspect) dealing with char->int
conversion while 4.6 doesn't generate them.

Asm for 4.7 for lines 42-47 from the testcase:

.LVL7:
        # test_4_6.c:42
        .loc 1 42 0 discriminator 2
        movl    8(%esp), %edx
        # test_4_6.c:45
        .loc 1 45 0 discriminator 2
        movl    0(,%edi,4), %esi
        # test_4_6.c:42
        .loc 1 42 0 discriminator 2
        movzbl  (%edx,%eax), %edx    <---- edx contains cb frome line 42
        # test_4_6.c:40
        .loc 1 40 0 discriminator 2
        addl    $1, %eax
        # test_4_6.c:45
        .loc 1 45 0 discriminator 2
        addl    %ebx, %esi
        # test_4_6.c:42
        .loc 1 42 0 discriminator 2
        movb    %dl, 3(%esp)          <----- spill, line 42
.LVL8:
        # test_4_6.c:45
        .loc 1 45 0 discriminator 2
        movzbl  (%esi), %edx
        # test_4_6.c:47
        .loc 1 47 0 discriminator 2
        movzbl  3(%esp), %esi         <----- fill, line 47
        # test_4_6.c:45
        .loc 1 45 0 discriminator 2
        movb    %dl, (%ecx)
        # test_4_6.c:47
        .loc 1 47 0 discriminator 2
        movl    0(,%esi,4), %edx     <------- using cb, line 47
        addl    0(,%edi,4), %edx
        sarl    $16, %edx
        # test_4_6.c:46
        .loc 1 46 0 discriminator 2
        movzbl  (%ebx,%edx), %edx
        # test_4_6.c:49
        .loc 1 49 0 discriminator 2
        addl    0(,%esi,4), %ebx      <----- using cb, line 49


 Meanwhile, 4.6 does not have such problem:

.LVL7:
        # test_4_6.c:42
        .loc 1 42 0 discriminator 2
        movl    4(%esp), %edx
        movzbl  (%edx,%eax), %esi <-- esi=cb and is used later without spills
.LVL8:
        # test_4_6.c:40
        .loc 1 40 0 discriminator 2
        addl    $1, %eax
        # test_4_6.c:45
        .loc 1 45 0 discriminator 2
        movl    0(,%edi,4), %edx
        addl    %ebx, %edx
        movzbl  (%edx), %edx
        movb    %dl, (%ecx)
        # test_4_6.c:47
        .loc 1 47 0 discriminator 2
        movl    0(,%esi,4), %edx    <---- using cb, line 47
        addl    0(,%edi,4), %edx
        sarl    $16, %edx
        # test_4_6.c:46
        .loc 1 46 0 discriminator 2
        movzbl  (%ebx,%edx), %edx
        # test_4_6.c:49
        .loc 1 49 0 discriminator 2
        addl    0(,%esi,4), %ebx   <---- using cb, line 49

 After expanding 4.7 contains:

(insn 52 51 53 6 (set (reg:QI 83 [ D.2723 ])
        (mem:QI (plus:SI (reg/v/f:SI 75 [ inptr1 ])
                (reg/v:SI 117 [ col ])) [0 MEM[base: inptr1_19, index: col_90,
offset: 0B]+0 S1 A8])) test_4_6.c:42 -1
     (nil))

 and 4.6 contains

(insn 52 51 53 6 (parallel [
            (set (reg/v:SI 86 [ cb ])
                (zero_extend:SI (mem:QI (plus:SI (reg/v/f:SI 76 [ inptr1 ])
                            (reg/v:SI 78 [ col ])) [0 MEM[base: inptr1_19, 
index: col_22, offset: 0B]+0 S1 A8])))
            (clobber (reg:CC 17 flags))
        ]) test_4_6.c:42 -1
     (nil))


Options are: -c -g -m32 -O2 test.c


GCC 4.6 is 

Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/export/users/izamyati/prefix
Thread model: posix
gcc version 4.6.0 20110215 (experimental) (GCC)

GCC 4.7 is 

Target: x86_64-unknown-linux-gnu
Configured with: ../configure --disable-bootstrap --enable-languages=c,c++
--prefix=/export/users/izamyati/prefix_4_7
Thread model: posix
gcc version 4.7.0 20110824 (experimental) (GCC)

[Bug target/50176] [4.6/4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.7.0

[Bug target/50176] [4.6/4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> 2011-08-24 18:09:44 UTC ---
Is this only a 4.7 regression?

[Bug target/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[izamyatin at gmail dot com]

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

--- Comment #2 from Igor Zamyatin <izamyatin at gmail dot com> 2011-08-25 13:17:36 UTC ---
For gcc with 
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --disable-bootstrap --enable-languages=c,c++
--prefix=/export/users/izamyati/gcc_4_6_2_prefix/
Thread model: posix
gcc version 4.6.2 20110825 (prerelease) (GCC)

everything is fine, no that spill-fill generated

[Bug target/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> 2011-08-25 13:56:52 UTC ---
(In reply to comment #2)
> For gcc with 
> Target: x86_64-unknown-linux-gnu
> Configured with: ../configure --disable-bootstrap --enable-languages=c,c++
> --prefix=/export/users/izamyati/gcc_4_6_2_prefix/
> Thread model: posix
> gcc version 4.6.2 20110825 (prerelease) (GCC)
> 
> everything is fine, no that spill-fill generated

Can we find which checkin caused this?

[Bug target/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2011-08-26
     Ever Confirmed|0                           |1

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> 2011-08-26 21:42:10 UTC ---
Can you verify if revision 173612:

http://gcc.gnu.org/ml/gcc-cvs/2011-05/msg00390.html

causes this regression?

[Bug target/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[izamyatin at gmail dot com]

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

--- Comment #5 from Igor Zamyatin <izamyatin at gmail dot com> 2011-08-29 11:48:12 UTC ---
Yes, looks like this revision is the reason

[Bug target/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
                 CC|                            |rguenth at gcc dot gnu.org

[Bug target/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #6 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-08-29 13:50:56 UTC ---
It performs perfectly sensible optimizations:

@@ -91,11 +83,9 @@
   y_33 = (int) D.2055_32;
   D.2056_34 = inptr1_19 + col_5;
   D.2057_35 = *D.2056_34;
-  cb_36 = (int) D.2057_35;
   D.2058_37 = inptr2_24 + col_5;
   D.2059_38 = *D.2058_37;
-  cr_39 = (int) D.2059_38;
-  cr.0_40 = (unsigned int) cr_39;
+  cr.0_40 = (unsigned int) D.2059_38;
...
@@ -104,12 +94,11 @@
   D.2066_48 = range_limit_47(D) + D.2065_46;
   D.2067_49 = *D.2066_48;
   *outptr_4 = D.2067_49;
-  D.2068_50 = outptr_4 + 1;
-  cb.1_51 = (unsigned int) cb_36;
+  cb.1_51 = (unsigned int) D.2057_35;
   D.2070_52 = cb.1_51 * 4;
   D.2071_54 = Cbgtab_53(D) + D.2070_52;
   D.2072_55 = *D.2071_54;
-  cr.0_56 = (unsigned int) cr_39;
+  cr.0_56 = (unsigned int) D.2059_38;
   D.2061_57 = cr.0_56 * 4;
   D.2073_59 = Crgtab_58(D) + D.2061_57;
   D.2074_60 = *D.2073_59;

This seems to be at most a register allocation or target issue.

What it does is change (unsinged)(int)*load to (unsigned)*load,
eventually enlarging life-ranges (didn't double-check that).

[Bug target/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[izamyatin at gmail dot com]

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

--- Comment #7 from Igor Zamyatin <izamyatin at gmail dot com> 2011-09-14 14:30:35 UTC ---
In RTL everythin is vice-versa, additional instruction appears:

For the "bad" case couple instructions are responsible for cb load (asmcons
dump):

(insn 52 51 53 5 (set (reg:QI 83 [ D.2685 ])
          (mem:QI (plus:SI (reg/v/f:SI 75 [ inptr1 ])
                  (reg/v:SI 117 [ col ])) [0 MEM[base: inptr1_19, index:
col_90, offset: 0B]+0 S1 A8])) ../test_bad_4_6.c:42 66 {*movqi_internal}
       (nil))

and later 

 (insn 62 61 122 5 (parallel [
              (set (reg:SI 152 [ D.2685 ])
                  (zero_extend:SI (reg:QI 83 [ D.2685 ])))
              (clobber (reg:CC 17 flags))
          ]) ../test_bad_4_6.c:47 123 {*zero_extendqisi2_movzbl_and}
       (expr_list:REG_DEAD (reg:QI 83 [ D.2685 ])
          (expr_list:REG_UNUSED (reg:CC 17 flags)
              (nil))))


while in "good" case only one:

(insn 52 51 53 5 (parallel [
            (set (reg/v:SI 84 [ cb ])
                (zero_extend:SI (mem:QI (plus:SI (reg/v/f:SI 75 [ inptr1 ])
                            (reg/v:SI 119 [ col ])) [0 MEM[base: inptr1_19,
index: col_90, offset: 0B]+0 S1 A8])))
            (clobber (reg:CC 17 flags))
        ]) ../test_good_4_6.c:42 123 {*zero_extendqisi2_movzbl_and}
     (expr_list:REG_UNUSED (reg:CC 17 flags)
        (nil)))

 And life ranges in "bad" case became splitted:

 a34(r152): [71..82]
  ....
  a38(r83): [83..92]

 And in "good" case only:

  a34(r84): [71..90]

[Bug target/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[izamyatin at gmail dot com]

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

Igor Zamyatin <izamyatin at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmakarov at redhat dot com

--- Comment #8 from Igor Zamyatin <izamyatin at gmail dot com> 2011-09-16 14:35:34 UTC ---
I was checking coalescing part in IRA but it looks like coalescing is fine.

Adding Vladimir, maybe he could give some advice here

[Bug rtl-optimization/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
          Component|target                      |rtl-optimization

[Bug rtl-optimization/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[vmakarov at redhat dot com]

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

--- Comment #9 from Vladimir Makarov <vmakarov at redhat dot com> 2011-12-13 20:04:04 UTC ---
(In reply to comment #0)
> Created attachment 25088 [details]
> 
> 
>  After expanding 4.7 contains:
> 
> (insn 52 51 53 6 (set (reg:QI 83 [ D.2723 ])
>         (mem:QI (plus:SI (reg/v/f:SI 75 [ inptr1 ])
>                 (reg/v:SI 117 [ col ])) [0 MEM[base: inptr1_19, index: col_90,
> offset: 0B]+0 S1 A8])) test_4_6.c:42 -1
>      (nil))
> 
>  and 4.6 contains
> 
> (insn 52 51 53 6 (parallel [
>             (set (reg/v:SI 86 [ cb ])
>                 (zero_extend:SI (mem:QI (plus:SI (reg/v/f:SI 76 [ inptr1 ])
>                             (reg/v:SI 78 [ col ])) [0 MEM[base: inptr1_19, 
> index: col_22, offset: 0B]+0 S1 A8])))
>             (clobber (reg:CC 17 flags))
>         ]) test_4_6.c:42 -1
>      (nil))
> 
> 

The reason of different outcome in RA is that p83 generated by 4.7 we can use
only q regs vs. general regs for p86 generated by 4.6.  It decreases # of
possible hard regs for p83 in two times and failure to assign p83 a hard
register.  More accurately IRA assigns dx to p83 then reload spills p83 because
it needs a hard register then reload asks IRA to reassign a hard register to
p83 and IRA fails.

[Bug rtl-optimization/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-10 12:11:31 UTC ---
We are expanding from

  # BLOCK 5 freq:9100
  # PRED: 5 [91.0%]  (dfs_back,true,exec) 3 [91.0%]  (true,exec)
  # outptr_89 = PHI <outptr_77(5), outptr_26(3)>
  # col_90 = PHI <col_78(5), 0(3)>
  D.1396_32 = MEM[base: inptr0_14, index: col_90, offset: 0B];
  y_33 = (int) D.1396_32;
  D.1398_35 = MEM[base: inptr1_19, index: col_90, offset: 0B];  <----
  D.1400_38 = MEM[base: inptr2_24, index: col_90, offset: 0B];
  cr.0_40 = (unsigned int) D.1400_38;
  D.1402_41 = cr.0_40 * 4;
  D.1403_43 = Crrtab_42(D) + D.1402_41;
  D.1404_44 = *D.1403_43;
  D.1405_45 = D.1404_44 + y_33;
  D.1406_46 = (sizetype) D.1405_45;
  D.1407_48 = range_limit_47(D) + D.1406_46;
  D.1408_49 = *D.1407_48;
  MEM[base: outptr_89, offset: 0B] = D.1408_49;
  cb.1_51 = (unsigned int) D.1398_35;                  <----------
  D.1411_52 = cb.1_51 * 4;
  D.1412_54 = Cbgtab_53(D) + D.1411_52;
  D.1413_55 = *D.1412_54;
  D.1414_59 = Crgtab_58(D) + D.1402_41;
  D.1415_60 = *D.1414_59;
  D.1416_61 = D.1413_55 + D.1415_60;
  D.1417_62 = D.1416_61 >> 16;
  D.1418_63 = D.1417_62 + y_33;
  D.1419_64 = (sizetype) D.1418_63;
  D.1420_65 = range_limit_47(D) + D.1419_64;
  D.1421_66 = *D.1420_65;
  MEM[base: outptr_89, offset: 1B] = D.1421_66;
  D.1423_71 = Cbbtab_70(D) + D.1411_52;
  D.1424_72 = *D.1423_71;
  D.1425_73 = D.1424_72 + y_33;
  D.1426_74 = (sizetype) D.1425_73;
  D.1427_75 = range_limit_47(D) + D.1426_74;
  D.1428_76 = *D.1427_75;
  MEM[base: outptr_89, offset: 2B] = D.1428_76;
  outptr_77 = outptr_89 + 3;
  col_78 = col_90 + 1;
  if (col_78 != num_cols.2_88)
    goto <bb 5>;

where you can see that we could reduce the lifetime of a QImode register
in favor of a SImode register by moving the extension right after the load.
This is what both -fschedule-insns and -fschedule-insns -fsched-pressure
achieve (which have both good non-regressed code generation).

On the tree level there isn't really an issue apart from the fact that
after expansion combine sees

;; D.1398_35 = MEM[base: inptr1_19, index: col_90, offset: 0B];

(insn 47 46 0 (set (reg:QI 83 [ D.1398 ])
        (mem:QI (plus:SI (reg/v/f:SI 75 [ inptr1 ])
                (reg/v:SI 117 [ col ])) [0 MEM[base: inptr1_19, index: col_90,
offset: 0B]+0 S1 A8])) t.c:42 -1
     (nil))

...

;; MEM[base: outptr_89, offset: 0B] = D.1408_49;

....

(insn 54 53 0 (set (mem:QI (reg/v/f:SI 116 [ outptr ]) [0 MEM[base: outptr_89,
offset: 0B]+0 S1 A8])
        (reg:QI 150)) t.c:45 -1
     (nil))

;; D.1411_52 = cb.1_51 * 4;

(insn 55 54 56 (parallel [
            (set (reg:SI 151)
                (zero_extend:SI (reg:QI 83 [ D.1398 ])))
            (clobber (reg:CC 17 flags))
        ]) t.c:47 -1
     (nil))

thus there is a store between the load and the zero_extend (and combine
only combines forward, not backward):

  /* Verify that I2 and I1 are valid for combining.  */
  if (! can_combine_p (i2, i3, i0, i1, NULL_RTX, NULL_RTX, &i2dest, &i2src)

already fails.

This is a missed optimization on the RTL level.

[Bug rtl-optimization/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot
                   |                            |gnu.org

--- Comment #11 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-01-10 22:03:43 UTC ---
> thus there is a store between the load and the zero_extend (and combine
> only combines forward, not backward):
> 
>   /* Verify that I2 and I1 are valid for combining.  */
>   if (! can_combine_p (i2, i3, i0, i1, NULL_RTX, NULL_RTX, &i2dest, &i2src)
> 
> already fails.

combine is a peephole optimizer so you cannot ask it to combine insns with 8
other intervening insns between them.  It looks like we have a real problem
with extensions though and the good approach (backward combining) appears to be
that of the REE pass, but it's too limited for the time being.

[Bug rtl-optimization/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[rguenther at suse dot de]

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

--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> 2012-01-11 08:56:27 UTC ---
On Tue, 10 Jan 2012, ebotcazou at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50176
> 
> Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |ebotcazou at gcc dot
>                    |                            |gnu.org
> 
> --- Comment #11 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-01-10 22:03:43 UTC ---
> > thus there is a store between the load and the zero_extend (and combine
> > only combines forward, not backward):
> > 
> >   /* Verify that I2 and I1 are valid for combining.  */
> >   if (! can_combine_p (i2, i3, i0, i1, NULL_RTX, NULL_RTX, &i2dest, &i2src)
> > 
> > already fails.
> 
> combine is a peephole optimizer so you cannot ask it to combine insns with 8
> other intervening insns between them.  It looks like we have a real problem
> with extensions though and the good approach (backward combining) appears to be
> that of the REE pass, but it's too limited for the time being.

Yeah, it's a bit unfortunate that combines behavior depends on the
insn scheduling ...

[Bug rtl-optimization/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-01-11 09:13:54 UTC ---
> Yeah, it's a bit unfortunate that combines behavior depends on the
> insn scheduling ...

We do have a long-range, albeit limited, forward combining (fwprop) though.

[Bug rtl-optimization/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-30 16:07:01 UTC ---
Anyway, does this need to be P1?  I'm afraid most of the changes are going to
be stage1-ish material.

[Bug rtl-optimization/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-30 16:06:03 UTC ---
Created attachment 26517
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26517
patch

I've tried to implement a hack for this in fwprop (debug insn updating for that
not implemented yet), but it unfortunately doesn't work, as for the zero_extend
load from QImode mem insn we need before reload_completed a CC mode clobber, so
apply_change_group fails.  No idea how should such a thing be handled before
reload.  Although there is an insn that doesn't need to clobber CC (movzbl for
this testcase), that pattern isn't enabled until reload_completed.

[Bug rtl-optimization/50176] [4.7/4.8 Regression] 4.7 generates spill-fill dealing with char->int conversion

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.0                       |4.8.0
            Summary|[4.7 Regression] 4.7        |[4.7/4.8 Regression] 4.7
                   |generates spill-fill        |generates spill-fill
                   |dealing with char->int      |dealing with char->int
                   |conversion                  |conversion

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-31 10:46:49 UTC ---
After IRC discussion with Richard Guenther, postponing to 4.8.

[Bug rtl-optimization/50176] [4.7/4.8 Regression] 4.7 generates spill-fill dealing with char->int conversion

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P2

--- Comment #17 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-31 10:56:57 UTC ---
Dropping priority to P2.

[Bug rtl-optimization/50176] [4.7/4.8 Regression] 4.7 generates spill-fill dealing with char->int conversion

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-06-27 13:56:48 UTC ---
Created attachment 27711
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27711
gcc48-pr50176.patch

Here is an untested patch (hacked up on 4.7 branch, as the problem on this
testcase seems to be only latent on the trunk).
The patch will change a QImode load followed by SI=zext(QI) into a zero
extending load on the first insn and a noop move on the second insn (which
fwprop later optimizes even further.
I had to add one new insn pattern in i386.md for it to trigger.
But testing it now, it seems that that i386.md change alone is sufficient to
fix up this testcase, because the combiner merges the two patterns then.
I guess if it was different basic blocks it wouldn't, so am not sure if we want
also the fwprop change or not.
I'll bootstrap/regtest the i386.md change separately first.

[Bug rtl-optimization/50176] [4.7/4.8 Regression] 4.7 generates spill-fill dealing with char->int conversion

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-06-27 15:28:52 UTC ---
Ah, the i386.md part doesn't apply on the trunk, since
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184891
which seems to have fixed this issue for the case where the load and zero
extension is in the same bb.
So, do we want the fwprop.c change for the different bb case (not sure how hard
will it be to come up with a testcase)?

[Bug rtl-optimization/50176] [4.7/4.8 Regression] 4.7 generates spill-fill dealing with char->int conversion

[law at redhat dot com]

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

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com

--- Comment #20 from Jeffrey A. Law <law at redhat dot com> 2013-01-15 21:28:30 UTC ---
Jakub,

As far as I can tell, this is still a problem with the trunk; Uros's changes to
i386.md do not help with this problem.

I updated just the fwprop portion of your patch to work with the trunk and as
far as I can tell it resolves the problem completely, resulting in a loop which
is effectively the same as gcc-4.6. 

The patch doesn't look terribly complex -- enough that I think we could
consider it in stage3 as it does fix a clear performance regression.

My suggestion would be to submit this for 4.8; if you don't want to do that,
then let's downgrade to a P4 and attach it to 4.9 pending patches tracker
(BZ55996) that we should consider once 4.9 opens.

[Bug rtl-optimization/50176] [4.7/4.8 Regression] 4.7 generates spill-fill dealing with char->int conversion

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-16 11:22:23 UTC ---
Created attachment 29177
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29177
gcc48-pr50176.patch

Are you sure about it?  For me on the
http://gcc.gnu.org/bugzilla/attachment.cgi?id=25088
testcase with -m32 -O2 with the attached patch I get just minor RA changes:
-       movl(%esp), %edi
+       movl(%esp), %esi
        addl$3, %ecx
-       movl4(%esp), %esi
-       movzbl(%edi,%eax), %ebx
+       movl4(%esp), %edi
+       movzbl(%esi,%eax), %ebx
+       movzbl(%edi,%eax), %esi
        movzbl0(%ebp,%eax), %edi
-       movzbl(%esi,%eax), %esi
The fwprop extension is performed as can be seen in the dump, but the overall
effect isn't there.

[Bug rtl-optimization/50176] [4.7/4.8 Regression] 4.7 generates spill-fill dealing with char->int conversion

[law at redhat dot com]

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

--- Comment #22 from Jeffrey A. Law <law at redhat dot com> 2013-01-20 06:16:21 UTC ---
I must have been looking at something else; the 4.6 and trunk loops are
effectively the same, so this is no longer a regression.

We might will want the fwprop patch, so I've attached this to the 4.9 pending
patches meta bug.

[Bug rtl-optimization/50176] 4.7 generates spill-fill dealing with char->int conversion

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.0                       |4.8.1

--- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-22 14:45:53 UTC ---
GCC 4.8.0 is being released, adjusting target milestone.

[Bug rtl-optimization/50176] 4.7 generates spill-fill dealing with char->int conversion

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.1                       |4.8.2

--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.1 has been released.

[Bug rtl-optimization/50176] 4.7 generates spill-fill dealing with char->int conversion

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.2                       |4.8.3

--- Comment #25 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.2 has been released.

[Bug rtl-optimization/50176] 4.7 generates spill-fill dealing with char->int conversion

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50176

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.3                       |---