--- 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
--- 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
--- 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])
--- 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
--- 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, leav
--- 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:/
--- 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 d
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconfir
--- 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)
--- 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
--- 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
--- 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 a
--- 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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Component|rtl-optimization|target
14 matches
Mail list logo
