[Bug target/23524] [4.1 Regression]bigger version of mov + cmp produced

2005-11-03 Thread hubicka at gcc dot gnu dot org 


--- Comment #18 from hubicka at gcc dot gnu dot org  2005-11-03 22:32 
---
insn size is currently completely unused.  It was used for producing loop
instructions.
Honza


-- 


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

[Bug target/23524] [4.1 Regression]bigger version of mov + cmp produced

2005-11-03 Thread uros at kss-loka dot si 


--- Comment #17 from uros at kss-loka dot si  2005-11-03 10:05 ---
> > FYI: This problem is addressed in patch at
> > http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00116.html.
> 
> Do you know if your patch also fixes this PR?

  Unfortunatelly no... I don't know if insn size is considered during reload.


-- 


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

[Bug target/23524] [4.1 Regression]bigger version of mov + cmp produced

2005-11-02 Thread dann at godzilla dot ics dot uci dot edu 


--- Comment #16 from dann at godzilla dot ics dot uci dot edu  2005-11-03 
06:42 ---
(In reply to comment #15)
> (In reply to comment #11)
> > And FWIW there is also a problem with this insn, the length is wrong:
> > 
> > #(insn 11 46 47 0x2a955cc840 (set (reg:SI 0 eax [orig:61 x ] [61])
> > #(mem/f:SI (symbol_ref:SI ("x")) [5 x+0 S4 A32])) 44 {*movsi_1} 
> > (nil)
> > #(expr_list:REG_EQUIV (mem/f:SI (symbol_ref:SI ("x")) [5 x+0 S4 A32])
> > #(nil)))
> > A1   movlx, %eax # 11*movsi_1/1  [length = 6]
> 
> FYI: This problem is addressed in patch at
> http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00116.html.

Do you know if your patch also fixes this PR?


-- 


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

[Bug target/23524] [4.1 Regression]bigger version of mov + cmp produced

2005-11-02 Thread uros at kss-loka dot si 


--- Comment #15 from uros at kss-loka dot si  2005-11-03 06:29 ---
(In reply to comment #11)
> And FWIW there is also a problem with this insn, the length is wrong:
> 
> #(insn 11 46 47 0x2a955cc840 (set (reg:SI 0 eax [orig:61 x ] [61])
> #(mem/f:SI (symbol_ref:SI ("x")) [5 x+0 S4 A32])) 44 {*movsi_1} (nil)
> #(expr_list:REG_EQUIV (mem/f:SI (symbol_ref:SI ("x")) [5 x+0 S4 A32])
> #(nil)))
> A1   movlx, %eax # 11*movsi_1/1  [length = 6]

FYI: This problem is addressed in patch at
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00116.html.


-- 


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

[Bug target/23524] [4.1 Regression]bigger version of mov + cmp produced

2005-10-30 Thread mmitchel at gcc dot gnu dot org 


--- Comment #14 from mmitchel at gcc dot gnu dot org  2005-10-31 05:36 
---
I don't think this PR is, in-and-of-itself, is very interesting, as it's a
1-byte size increase with -O2, which, as has been said, is not aimed at
minimizing code size.  So, I'm going to close this PR -- but, leave PR 23153
open, as there look to be interesting issues there.


-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX


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

[Bug target/23524] [4.1 Regression]bigger version of mov + cmp produced

2005-10-30 Thread dann at godzilla dot ics dot uci dot edu 


--- Comment #13 from dann at godzilla dot ics dot uci dot edu  2005-10-31 
04:50 ---
(In reply to comment #12)
> A more interesting test would be to see the Linux kernel size difference,

There's such a comparison now in comment #8 in PR23153. It confirms the size
increase.


-- 


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

[Bug target/23524] [4.1 Regression]bigger version of mov + cmp produced

2005-10-27 Thread dann at godzilla dot ics dot uci dot edu 


--- Comment #12 from dann at godzilla dot ics dot uci dot edu  2005-10-27 
18:08 ---
(In reply to comment #9)
> And CSiBE tells you the story that GCC 4.1 produces smaller code overall.
> http://www.inf.u-szeged.hu/csibe/draw-diag.php?draw=sum-os&basephp=s-i686-linux

Well, it obviously depends on applications.
The point of PR23153 is to show that there is a code size regression, and all
the PRs that depend on it are showing very specific issues that cause a part of
the regression.

A more interesting test would be to see the Linux kernel size difference,
because if there's any difference there would be some people screaming
(unfortunately I won't be able to do that comparison anytime soon, hope someone
else will).


-- 


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

[Bug target/23524] [4.1 Regression]bigger version of mov + cmp produced

2005-10-27 Thread steven at gcc dot gnu dot org 


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|2005-10-27 17:34:42 |2005-10-27 17:35:05
   date||


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

[Bug target/23524] [4.1 Regression]bigger version of mov + cmp produced

2005-10-27 Thread steven at gcc dot gnu dot org 


--- Comment #11 from steven at gcc dot gnu dot org  2005-10-27 17:34 ---
And FWIW there is also a problem with this insn, the length is wrong:

#(insn 11 46 47 0x2a955cc840 (set (reg:SI 0 eax [orig:61 x ] [61])
#(mem/f:SI (symbol_ref:SI ("x")) [5 x+0 S4 A32])) 44 {*movsi_1} (nil)
#(expr_list:REG_EQUIV (mem/f:SI (symbol_ref:SI ("x")) [5 x+0 S4 A32])
#(nil)))
A1   movlx, %eax # 11*movsi_1/1  [length = 6]


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|-00-00 00:00:00 |2005-10-27 17:34:42
   date||


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

[Bug target/23524] [4.1 Regression]bigger version of mov + cmp produced

2005-10-27 Thread steven at gcc dot gnu dot org 


--- Comment #10 from steven at gcc dot gnu dot org  2005-10-27 17:31 ---
For the record, we're talking about:

   1.file   "t.c"
   2.text
   3.p2align 4,,15
   4.globl foo
   5.type   foo, @function
   6foo:
   7  55pushl   %ebp
   8 0001 A100  movlx, %eax
   8  00
   9 0006 89E5  movl%esp, %ebp
  10 0008 8B5508movl8(%ebp), %edx
  11 000b 394204cmpl%eax, 4(%edx)
  12 000e 7402  je  .L4
  13 0010 5Dpopl%ebp
  14 0011 C3ret
  15.p2align 4,,7
  16.L4:
  17 0012 5Dpopl%ebp
  18 0013 E9FC  jmp bar
  18  FF
  19.size   foo, .-foo
  20.comm   x,4,4
  21.section.note.GNU-stack,"",@progbits
  22.ident  "GCC: (GNU) 3.3.4 (pre 3.3.5 20040809)"




vs.


   1.file   "t.c"
   2.text
   3.p2align 4,,15
   4.globl foo
   5.type   foo, @function
   6foo:
   7  55pushl   %ebp
   8 0001 89E5  movl%esp, %ebp
   9 0003 8B5508movl8(%ebp), %edx
  10 0006 8B4204movl4(%edx), %eax
  11 0009 3B05  cmplx, %eax
  11  
  12 000f 7402  je  .L6
  13 0011 5Dpopl%ebp
  14 0012 C3ret
  15.p2align 4,,7
  16.L6:
  17 0013 5Dpopl%ebp
  18 0014 E9FC  jmp bar
  18  FF
  19.size   foo, .-foo
  20.comm   x,4,4
  21.ident  "GCC: (GNU) 4.1.0 20051026
(experimental)"
  22.section.note.GNU-stack,"",@progbits


-- 


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

[Bug target/23524] [4.1 Regression]bigger version of mov + cmp produced

2005-10-27 Thread steven at gcc dot gnu dot org 


--- Comment #9 from steven at gcc dot gnu dot org  2005-10-27 17:08 ---
And CSiBE tells you the story that GCC 4.1 produces smaller code overall.
http://www.inf.u-szeged.hu/csibe/draw-diag.php?draw=sum-os&basephp=s-i686-linux

So do the SPEC benchmark boxes btw.


-- 


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

[Bug target/23524] [4.1 Regression]bigger version of mov + cmp produced

2005-10-27 Thread dann at godzilla dot ics dot uci dot edu 


--- Comment #8 from dann at godzilla dot ics dot uci dot edu  2005-10-27 
16:43 ---
(In reply to comment #7)
> Could the dear reported at least try to provide a small test case?

The testcase in the attachment contains only a 4 lines function: 
HandleDeIconify, the rest is just fluff to allow it to compile. Granted a lot
of it can be pruned, but I don't think it stops trying to debug the problem.


> I think this should not be marked as a regression.  

Why not? It is a regression. 

> It's just sad that this
> kind of non-bug keeps the regression count high, when in reality GCC 4.1
> produces smaller code overall.

PR23153 tells a completely different story about codesize (at least for i686).


-- 


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

[Bug target/23524] [4.1 Regression]bigger version of mov + cmp produced

2005-10-27 Thread steven at gcc dot gnu dot org 


--- Comment #7 from steven at gcc dot gnu dot org  2005-10-27 16:26 ---
Could the dear reported at least try to provide a small test case?

I think this should not be marked as a regression.  It's just sad that this
kind of non-bug keeps the regression count high, when in reality GCC 4.1
produces smaller code overall.



-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug target/23524] [4.1 Regression]bigger version of mov + cmp produced

2005-10-25 Thread pinskia at gcc dot gnu dot org 


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |minor
  Component|rtl-optimization|target
   Keywords||missed-optimization
Summary|bigger version of mov + cmp |[4.1 Regression]bigger
   |produced|version of mov + cmp
   ||produced
   Target Milestone|--- |4.1.0


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