--- Comment #2 from dann at godzilla dot ics dot uci dot edu 2010-04-22
19:54 ---
(In reply to comment #1)
> >Also "pretmp" "prehitmp" and "ivtmp" prefixes are too long,
>
> They might be too long but they are useful long without looking t
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43855
aries are too long
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43854
--- Comment #8 from dann at godzilla dot ics dot uci dot edu 2009-06-25
15:31 ---
(In reply to comment #7)
> With the new restrict implementation baz() works and all the rest would work
> as well if the calls to link_error () would not cause the malloced memory
> to be clobbe
--- Comment #3 from dann at godzilla dot ics dot uci dot edu 2009-02-02
16:42 ---
(In reply to comment #2)
> (reminds me of a couple missed-optimization PRs where vectorization is also
> failing due to casts - PR31873 , PR26128 - don't know if this is related)
Are the cas
--- Comment #1 from dann at godzilla dot ics dot uci dot edu 2009-02-02
14:50 ---
This code:
unsigned short a[1];
void test()
{
int i;
for (i = 0; i < 1; ++i) a[i] = 5;
}
will be vectorized with -O3 -march=core2 to this:
.L2:
movdqa %xmm0, a(%eax)
a
t org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39075
FIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39068
FIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39069
--- Comment #6 from dann at godzilla dot ics dot uci dot edu 2008-11-20
23:27 ---
Still happens in 4.4.
--
dann at godzilla dot ics dot uci dot edu changed:
What|Removed |Added
--- Comment #4 from dann at godzilla dot ics dot uci dot edu 2008-11-20
18:43 ---
Still happens with 4.4.0:
qqq (int a)
{
int result.0;
int D.1236;
int result;
result.0 = bar (a);
result = result.0;
D.1236 = result;
return D.1236;
}
--
dann at godzilla dot ics dot
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC host triplet: i386-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38204
--- Comment #8 from dann at godzilla dot ics dot uci dot edu 2008-03-15
00:28 ---
(In reply to comment #7)
> The testcase is fixed by the SCCVN alias-oracle patch.
Are you sure? I still see the problem (.final_cleanup dump):
void bar(first*, multi*) (s1, s3)
{
:
s1->f1 = 0
--- Comment #9 from dann at godzilla dot ics dot uci dot edu 2008-03-04
21:43 ---
(In reply to comment #8)
> Subject: Re: adding unused char field inhibits
> optimization
>
> On Tue, 4 Mar 2008, dann at godzilla dot ics dot uci dot edu wrote:
>
> > --- Co
--- Comment #7 from dann at godzilla dot ics dot uci dot edu 2008-03-04
21:32 ---
(In reply to comment #6)
> Actually RTL alias is just using the same routines.
Might be, but the RTL level code that optimizes away the abort() in both
testcases (if I remember w
--- Comment #5 from dann at godzilla dot ics dot uci dot edu 2008-03-04
21:19 ---
(In reply to comment #4)
> http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00243.html
Thanks for working on this!
Have you looked at the impact?
Probably the generated code won't too different bec
--- Comment #2 from dann at godzilla dot ics dot uci dot edu 2007-04-14
21:03 ---
(In reply to comment #1)
> This looks completely a register allocator issue and I think 4.2.0 and before
> were just getting lucky.
Also note that the extra push+pop are NOT generated when using
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31575
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30643
--- Comment #5 from dann at godzilla dot ics dot uci dot edu 2007-01-28
22:04 ---
(In reply to comment #2)
> i.e. it misses to initialize the temporary with the result. Otherwise you
> can play with variants of the following patch:
Richard, have you tried to make this patch wo
--- Comment #6 from dann at godzilla dot ics dot uci dot edu 2006-12-12
06:07 ---
(In reply to comment #5)
> (In reply to comment #1)
> > Confirmed (but it's not PRE).
> >
> The second is smaller, and no more or less efficient since the addition is
> calcu
--- Comment #4 from dann at godzilla dot ics dot uci dot edu 2006-12-07
18:24 ---
(In reply to comment #3)
> unswitching would duplicate the whole loop here, so not exactly I think. But
> if-conversion to
>
> j = COND_EXPR
>
> or
>
> j = 2 - (int)p
4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30105
ant control
structures)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot
UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30103
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.o
The following 2 functions should be compiled to the same assembly.
This is one of Briggs' compiler benchmarks.
void vnum_test12(int *data)
{
int n;
int stop = data[3];
int j = data[1];
int k = j;
int i = 1;
for (n=0; nhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=30101
The following 2 functions should be compiled to the same assembly.
This is one of Briggs' compiler benchmarks.
void vnum_test11(int *data)
{
int n;
int stop = data[3];
int j = data[1];
int k = j;
int i = 1;
for (n=0; nhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=30100
4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gn
The following 2 functions should be compiled to the same thing.
This is a test from Briggs' compiler benchmarks.
void vnum_test8(int *data)
{
int i;
int stop = data[3];
int m = data[4];
int n = m;
for (i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=30098
--- Comment #3 from dann at godzilla dot ics dot uci dot edu 2006-09-04
17:56 ---
This specific case can probably be solved at the tree level by changing the
test:
(nb >> 5) != 0
to
nb > 32
--
dann at godzilla dot ics dot uci dot edu changed:
What
--- Comment #3 from dann at godzilla dot ics dot uci dot edu 2006-06-20
19:09 ---
More data: for PR8361 the number of functions in the .gimple dump is 5045, the
number of functions in the cleanup_cfg dump is 1341. The majority of the
functions that are eliminated are small functions
--- Comment #3 from dann at godzilla dot ics dot uci dot edu 2006-06-13
14:42 ---
One of the issues with this PR and also 27800, 27809 and 27810 is that this
extra work/memory allocation done for a number of functions that are never
used: like all the inline functions present in the
--- Comment #3 from dann at godzilla dot ics dot uci dot edu 2006-06-13
14:22 ---
(In reply to comment #2)
> (In reply to comment #1)
> > Hmm, it should have produced G.3, G.n, at least I would have thought.
> >
>
> No, we intentionally use the same varia
--- Comment #2 from dann at godzilla dot ics dot uci dot edu 2006-06-13
14:18 ---
Add Diego to the CC list as per his request.
--
dann at godzilla dot ics dot uci dot edu changed:
What|Removed |Added
wering for return
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot
--- Comment #2 from dann at godzilla dot ics dot uci dot edu 2006-05-31
21:47 ---
My guesstimate is that for combine.i about 5-8% of the total number of
expressions
in the gimple dump are due to the gimplification inefficiencies shown in
PRs 27798 27800 27809 27810, so these issues
D
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27810
globals
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http
--- Comment #1 from dann at godzilla dot ics dot uci dot edu 2006-05-29
20:51 ---
An even simpler example which occurs quite frequently in programs:
int jjj (int a){ return bar (a); }
jjj (a)
{
int D.1891;
int D.1892;
D.1892 = bar (a);
D.1891 = D.1892;
return D.1891
ty: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27800
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27799
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27798
gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #2 from dann at godzilla dot ics dot uci dot edu 2006-05-04
23:09 ---
(In reply to comment #1)
> IV-OPTs just gets info from the target. Now if the target says weird
> addressing mode is the same as cheap ones, what do you think will happen?
Does IV-OPTs also tak
nassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27440
--- Comment #8 from dann at godzilla dot ics dot uci dot edu 2006-05-03
21:53 ---
WRT this code generated by tree-ch:
D.1305_41 = Int_Loc_3 + 1;
if (Int_Loc_3 <= D.1305_41) goto ; else goto ;
AFAICT there's exactly one value for which the comparison can be false, IMO it
--- Comment #5 from dann at godzilla dot ics dot uci dot edu 2006-05-03
18:54 ---
IMO Comment #4 does not look close enough at what is actually happening.
IMO tree-ch is the root cause here.
The code looks like this before .ch
Before .ch
goto ();
:;
D.1301_54 = Int_Loc.0_4 * 200
--- Comment #28 from dann at godzilla dot ics dot uci dot edu 2006-04-30
19:25 ---
Just a note, fixing the problem in this PR would fix the only remaining failure
for cprop in Brigg's compiler benchmarks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15911
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27365
ot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26949
--- Comment #2 from dann at godzilla dot ics dot uci dot edu 2006-03-30
16:43 ---
(In reply to comment #1)
> Note that this may be also PRE confusing SCEV in presence of loop headers.
Talking about PRE, here's a maybe interesting observation in the PRE dump:
:;
pret
ONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26944
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26850
--- Comment #18 from dann at godzilla dot ics dot uci dot edu 2006-03-03
02:14 ---
(In reply to comment #17)
> (In reply to comment #5)
> > It's strange that the load(*) does not get optimized, given that it's in the
> > same BB as t
153.
--
Summary: Basic block reordering inserts redundant instruction
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu
--- Comment #4 from dann at godzilla dot ics dot uci dot edu 2006-02-13
02:34 ---
Here's another testcase of what seems to be the same problem.
The 4.2 assembly contains 2 calls for TabSet, 4.0 only has 1.
(both this and the first example are function from xterm in case an
gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26251
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26249
--- Comment #9 from dann at godzilla dot ics dot uci dot edu 2006-01-05
20:22 ---
(In reply to comment #7)
> *** Bug 23338 has been marked as a duplicate of this bug. ***
>
Bug 23338 contained a patch that might fixed this issue. Here it is, so
that it can be evaluated.
*** i
--- Comment #6 from dann at godzilla dot ics dot uci dot edu 2005-12-18
22:57 ---
(In reply to comment #5)
> Simplified testcase seems to work for me on 4.1 branch:
> restore_fpu:
> movl4(%esp), %edx
> movlboot_cpu_data+12, %eax
> testl
timal code generated for coparisons on Sparc
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzi
--- Comment #2 from dann at godzilla dot ics dot uci dot edu 2005-11-13
02:47 ---
Simplified testcase:
struct cpuinfo_x86 {
unsigned char x86;
unsigned char x86_vendor;
unsigned char x86_model;
unsigned char x86_mask;
char wp_works_ok;
char hlt_works_ok;
char hard_math
--- Comment #1 from dann at godzilla dot ics dot uci dot edu 2005-11-11
19:29 ---
Created an attachment (id=10220)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10220&action=view)
Preprocessed code containing the functions that exhibit the problem
--
http://gcc.
ion: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.or
--- Comment #12 from dann at godzilla dot ics dot uci dot edu 2005-11-03
07:51 ---
(In reply to comment #11)
> (In reply to comment #10)
> > I am not sure what kind of answer you expect here.
> > Speed and code size are not disjoint. Think about I-cache and I-TLB miss
--- 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
--- Comment #10 from dann at godzilla dot ics dot uci dot edu 2005-11-03
02:34 ---
(In reply to comment #9)
> Have you tested the speed? As I said I really doubt it makes a real world
> change in terms of speed. This is different from code size.
I am not sure what kind of answ
--- Comment #8 from dann at godzilla dot ics dot uci dot edu 2005-11-03
02:12 ---
(In reply to comment #6)
> The use of ax vs cx will not matter in the real world.
This is from a real world program (xterm) and it seems to matter, when using
eax the code is smaller.
Are you sure t
--- Comment #5 from dann at godzilla dot ics dot uci dot edu 2005-11-03
01:27 ---
(In reply to comment #4)
> This is actually invalid as nothing happens for -Os case so what you are
> seeing
> is just an atrifact.
Sorry but this explanation for marking the PR invalid does
--- Comment #11 from dann at godzilla dot ics dot uci dot edu 2005-11-03
00:59 ---
A very useful tool for comparing function sizes in 2 binaries/object file is:
ftp://ftp.firstfloor.org/pub/ak/bloat-o-meter
it displays the function names, the size, the size difference as absolute
--- Comment #10 from dann at godzilla dot ics dot uci dot edu 2005-11-03
00:53 ---
(In reply to comment #9)
> What are the flags for the sizes in comment #7 and comment #8?
-O2 -march=i686
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23153
--- Comment #7 from dann at godzilla dot ics dot uci dot edu 2005-11-01
15:15 ---
(In reply to comment #5)
> Hmm,
> I am still not sure if it matters too much, but since there are actually
> dupes of this problem, I think we can simply add peep2 fixing this
> particular
--- 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.
--
--- Comment #8 from dann at godzilla dot ics dot uci dot edu 2005-10-31
04:15 ---
More data, the Linux kernel compiled for i686:
size -f *
textdata bss dec hex filename
2625471 534012 611768 3771251 398b73 vmlinux.4.0
3023306 429364 347384 3800054 39fbf6
--- 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
--- 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
--- Comment #1 from dann at godzilla dot ics dot uci dot edu 2005-10-05
05:13 ---
Created an attachment (id=9889)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9889&action=view)
preprocessed code for this bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24209
IRMED
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: sparc-sun-solaris2.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24209
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-29 20:10 ---
(In reply to comment #9)
> Subject: Re: Unconditional warning when using -combine
>
> On Mon, Sep 26, 2005 at 08:46:20PM -0000, dann at godzilla dot ics dot uci dot
edu wrote:
>
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-28 17:29 ---
(In reply to comment #2)
> While it might be probably possible to design peephole or combiner insn patter
> I am tempted to close this and PR 23303 as WONTFIX as it seems to me we was
> o
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-26 20:46 ---
(In reply to comment #4)
> So this about the following:
> int f(a)
> int a;
> {
> return a;
> }
> int f(int);
>
> Which is questionable.
>
> So I don
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-26 19:54 ---
(In reply to comment #4)
> Because one file uses K&R style function defintions and the other uses a
prototype which is ANSI/ISO
> style.
> Simple example:
[snip]
> So I don't
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-26 19:25 ---
Created an attachment (id=9808)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9808&action=view)
xlwmenu.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-26 19:25 ---
Created an attachment (id=9807)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9807&action=view)
xterm.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-21 17:43 ---
(In reply to comment #8)
> (In reply to comment #4)
> Instead of the above check, change it to:
> if (local_regparm == 3 && DECL_STRUCT_FUNCTION (fn)->static_chain_decl)
&
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-13 23:09 ---
Additional data:
For the testcase in PR8361:
size -f generate-3.4*.o
textdata bss dec hex filename
297025 4 181 297210 488fa generate-3.4-4.0.o
318366 8
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-13 22:57 ---
(In reply to comment #6)
> Maybe a better check would be check in the decl's function struct's
> field
> static_chain_decl is set.
I am not sure I understand what you mean her
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-13 22:36 ---
It looks like the -fwhole-program version of ClearLeft only passes the
first 2 arguments to the ClearInLine call in register, the 3rd one is
passed on the stack.
The reason for that is this code
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-13 20:45 ---
The fact that the dump is different depending on function order or compilation
flags seems to point to either an uninitialized variable or some memory
corruption.
--
http://gcc.gnu.org
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-12 23:30 ---
(In reply to comment #1)
> If it changes calling-conventions
> in single-file compile mode the function must be declared static, so it
> definitely may be changed in whole-program mode,
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC targe
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-07 22:05 ---
It seems that expand generates different insns in 4.0 and 4.1 for the comparison
in question:
4.0 generates: (from .00.expand)
(insn 15 13 16 1 (set (reg/f:SI 62)
(mem/s/f:SI (plus:SI
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-08-25 05:43 ---
The issue is the peephole2 pass in 4.1. Before it the insn looks like:
(insn:HI 36 34 37 0 (set (mem/i:SI (symbol_ref:SI ("waiting_for_initial_map")
[flags 0x40] ) [7
waiting_for_initia
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-08-25 02:49 ---
This message:
http://gcc.gnu.org/ml/gcc/2005-08/msg00208.html
was asking for the reason for the slowdown for S05e
AFAICT the inner loop for the benchmark (in s05e_test) gets compiled to
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-08-23 18:15 ---
(In reply to comment #4)
>
> Then use -Os every where instead. You will see that the overall code
> size for 4.1
> has reduced from 4.0.
That might be true, but -Os is not always a
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-08-23 18:05 ---
(In reply to comment #2)
> You really should know that we only care about code size at -Os. We care
about performance
> regressions though at -O2.
Code size is important for performan
: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23525
1 - 100 of 132 matches
Mail list logo
