--- Comment #2 from hubicka at gcc dot gnu dot org 2009-11-30 17:29 ---
With 4.5 we seem to be all fine here:
j...@gcc17:~/trunk/build/gcc$ ./g++ -B ./ -O2 tt.c -fdump-tree-all-details -S
-fdump-rtl-all-details-blocks
j...@gcc17:~/trunk/build/gcc$ more tt.s
.file tt.c
--- Comment #4 from hubicka at gcc dot gnu dot org 2009-11-23 22:04 ---
Fixed.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #2 from hubicka at gcc dot gnu dot org 2009-11-23 22:27 ---
Subject: Bug 42151
Author: hubicka
Date: Mon Nov 23 22:27:15 2009
New Revision: 154475
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154475
Log:
PR middle-end/42151
* ipa-inline.c
--- Comment #3 from hubicka at gcc dot gnu dot org 2009-11-23 22:30 ---
Fixed.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
Status
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hubicka at gcc dot gnu dot org
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hubicka at gcc dot gnu dot org
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hubicka at gcc dot gnu dot org
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla
--- Comment #4 from hubicka at gcc dot gnu dot org 2009-11-12 12:34 ---
Works for me now with -flto and -fwhopr.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from hubicka at gcc dot gnu dot org 2009-11-12 12:37 ---
Fixed by my patch.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from hubicka at gcc dot gnu dot org 2009-11-12 12:42 ---
Fixed by my patch.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from hubicka at gcc dot gnu dot org 2009-11-12 13:23 ---
There are some bugs on LTO and unused vars elimination, but in this testcase we
end up with:
main:
.LFB2:
subq$8, %rsp
.LCFI0:
movly(%rip), %esi
movl$.LC0, %edi
xorl
--- Comment #12 from hubicka at gcc dot gnu dot org 2009-11-12 23:52
---
When we use summaries at LTO as well as on WHOPR, we get better testing
coverage for the summary streaming code, somewhat faster linktime (avoiding
need to produce them) and we should make it possible for LTO
--- Comment #1 from hubicka at gcc dot gnu dot org 2009-11-11 22:15 ---
This seems to be some issue with EH producing type infos too early.
LDFCM0 appears there is action record:
.LLSDACSE1:
.byte 0x1 # Action record table
.byte 0x0
.align 4
.long
--- Comment #3 from hubicka at gcc dot gnu dot org 2009-11-11 22:23 ---
Testing patch.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #4 from hubicka at gcc dot gnu dot org 2009-11-11 23:45 ---
Subject: Bug 41735
Author: hubicka
Date: Wed Nov 11 23:45:09 2009
New Revision: 154108
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154108
Log:
PR middle-end/41729
* ipa.c
--- Comment #2 from hubicka at gcc dot gnu dot org 2009-11-11 23:45 ---
Subject: Bug 41729
Author: hubicka
Date: Wed Nov 11 23:45:09 2009
New Revision: 154108
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154108
Log:
PR middle-end/41729
* ipa.c
--- Comment #4 from hubicka at gcc dot gnu dot org 2009-10-22 11:40 ---
Subject: Bug 40556
Author: hubicka
Date: Thu Oct 22 11:40:18 2009
New Revision: 153450
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153450
Log:
PR tree-optimize/40556
--- Comment #5 from hubicka at gcc dot gnu dot org 2009-10-22 13:32 ---
Subject: Bug 41730
Author: hubicka
Date: Thu Oct 22 13:31:48 2009
New Revision: 153456
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153456
Log:
* ipa-cp.c (ipcp_read_summary): Remove now invalid
--- Comment #6 from hubicka at gcc dot gnu dot org 2009-10-22 13:32 ---
Subject: Bug 40556
Author: hubicka
Date: Thu Oct 22 13:31:48 2009
New Revision: 153456
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153456
Log:
* ipa-cp.c (ipcp_read_summary): Remove now invalid
--- Comment #3 from hubicka at gcc dot gnu dot org 2009-10-21 23:58 ---
Actually it catch quite interesting thinko in early inliner. We cut iterations
of early inliner after fixed point of iterations but because of way the exit
condition is written we end up not applying the inline
--- Comment #3 from hubicka at gcc dot gnu dot org 2009-10-08 10:07 ---
Subject: Bug 41620
Author: hubicka
Date: Thu Oct 8 10:06:52 2009
New Revision: 152556
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152556
Log:
PR bootstrap/41620
* ipa.c
are
not getting debug statements.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: aoliva at gcc dot gnu dot org
ReportedBy: hubicka at gcc dot
--- Comment #6 from hubicka at gcc dot gnu dot org 2009-07-28 16:38 ---
Subject: Bug 40759
Author: hubicka
Date: Tue Jul 28 16:37:50 2009
New Revision: 150168
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150168
Log:
PR tree-optimization/40759
* tree-ssa-dce.c
--- Comment #8 from hubicka at gcc dot gnu dot org 2009-07-19 10:27 ---
Subject: Bug 40676
Author: hubicka
Date: Sun Jul 19 10:27:07 2009
New Revision: 149789
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149789
Log:
PR tree-optimization/40676
* tree-ssa-dce.c
--- Comment #10 from hubicka at gcc dot gnu dot org 2009-07-12 12:07
---
Subject: Bug 40585
Author: hubicka
Date: Sun Jul 12 12:07:35 2009
New Revision: 149530
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149530
Log:
PR tree-optimization/40585
* except.c
--- Comment #8 from hubicka at gcc dot gnu dot org 2009-07-11 19:08 ---
Fixed.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from hubicka at gcc dot gnu dot org 2009-07-11 22:34 ---
OK,
this is interesting case. We have:
# BLOCK 6
# PRED: 2 [61.0%] (true,exec) 3 [61.0%] (true,exec) 4 [39.0%] (true,exec)
5 [100.0%] (fallthru,exec)
# D.2735_12 = PHI 0(2), 0(3), 0(4), 1(5)
# .MEM_21
--- Comment #6 from hubicka at gcc dot gnu dot org 2009-06-30 12:44 ---
Created an attachment (id=18100)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18100action=view)
Proposed patch
The problem is that early inliner allows to increase code size estimate by
inlining single
--- Comment #13 from hubicka at gcc dot gnu dot org 2009-06-30 13:36
---
Hmm,
looking at the cases it seems that main reason for the win is the fact that
idiv needs integer load instruction that has long immediate and we don't
optimize these for -Os well.
I suppose for -Os following
--- Comment #9 from hubicka at gcc dot gnu dot org 2009-06-30 13:41 ---
I can schedule it for nightly testing today, but if you have easier setup for
CSiBE, it would help :)
Thanks!
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
--- Comment #11 from hubicka at gcc dot gnu dot org 2009-06-09 15:18
---
Hmm, it is not exactly load. In first case I get:
(code_label 12524 16482 12523 70 1249 [4 uses])
(note 12523 12524 149 70 [bb 70] NOTE_INSN_BASIC_BLOCK)
(insn:TI 149 12523 13690 70 ../src/Include/ceval-vm.i
--- Comment #2 from hubicka at gcc dot gnu dot org 2009-06-08 15:54 ---
The loops should be in sync, but I am but confused here.
I originally added the code only when walking types, not actual declarations,
since in decls we don't use that VOIDtype terminator. There was some side case
--- Comment #4 from hubicka at gcc dot gnu dot org 2009-06-08 17:18 ---
Subject: Bug 40102
Author: hubicka
Date: Mon Jun 8 17:17:52 2009
New Revision: 148287
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148287
Log:
PR middle-end/40102
* cgraph.c
--- Comment #5 from hubicka at gcc dot gnu dot org 2009-06-08 17:20 ---
Fixed.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #7 from hubicka at gcc dot gnu dot org 2009-06-08 18:34 ---
OK,
problem seems to be that we keep stale location list hash that confuse
dwarf2out when outputting abstract function
Index: dwarf2out.c
--- Comment #4 from hubicka at gcc dot gnu dot org 2009-06-08 19:21 ---
Subject: Bug 39834
Author: hubicka
Date: Mon Jun 8 19:21:33 2009
New Revision: 148292
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148292
Log:
PR debug/39834
* gcc.dg/torture/pr39834.c
--- Comment #5 from hubicka at gcc dot gnu dot org 2009-06-08 19:22 ---
Fixed.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from hubicka at gcc dot gnu dot org 2009-06-08 19:26 ---
Subject: Bug 40126
Author: hubicka
Date: Mon Jun 8 19:25:51 2009
New Revision: 148293
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148293
Log:
PR debug/40126
* dwarf2out.c
--- Comment #9 from hubicka at gcc dot gnu dot org 2009-06-08 19:26 ---
Fixed.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from hubicka at gcc dot gnu dot org 2009-06-08 20:55 ---
Hmm,
the conditional is bogus, there should not be !
but still after patching this we don't duplicate. The reason is that the BB 71
(containing conditional jump) is reached via 2 BBs containing memory load. I
--- Comment #7 from hubicka at gcc dot gnu dot org 2009-06-06 13:41 ---
It seems to make sense to bump cost of idiv a bit, given the fact that there
are register pressure implications.
I would like to however understand what code sequences we produce that are
estimated to be long
--- Comment #6 from hubicka at gcc dot gnu dot org 2009-06-04 14:50 ---
There is simple algoritm reordering functions so calls more commonly leads to
following function in memory. (just order calls by frequency and concatenate
them into sequences and then order sequences to promote
--- Comment #7 from hubicka at gcc dot gnu dot org 2009-06-04 15:03 ---
Added testcase and closing the bug
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from hubicka at gcc dot gnu dot org 2009-05-14 15:29 ---
This looks like latent bug in dwarf2out. There is location list:
.LLST2:
.long .LVL0-.Ltext0 # Location list begin address (*.LLST2)
.long .LVL1-.Ltext0 # Location list end address (*.LLST2
--- Comment #1 from hubicka at gcc dot gnu dot org 2009-05-12 11:52 ---
Hmm, the inlined functions has loop depth of 4, that makes it predicted to
iterate quite few times. My guess would be that inlining increases loop depth
that in turn makes GCC to conclude that one of loops
--- Comment #2 from hubicka at gcc dot gnu dot org 2009-05-11 17:16 ---
It compiles for me at -O2 and x86_64-linux. I fixed bug with similar symptoms
last week, does it still reproduce?
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40100
--- Comment #5 from hubicka at gcc dot gnu dot org 2009-05-10 11:36 ---
Subject: Bug 40084
Author: hubicka
Date: Sun May 10 11:36:11 2009
New Revision: 147337
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147337
Log:
PR middle-end/40084
* cgraph.c
--- Comment #7 from hubicka at gcc dot gnu dot org 2009-05-10 17:06 ---
Fixed.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #1 from hubicka at gcc dot gnu dot org 2009-05-10 19:51 ---
This is latent problem in -Wunreachable.
We now unroll the loop:
void bar (void)
{
int i;
for (i = 0; i 2; i++)
if (! foo (a[i]))
return;
baz (); /* { dg-bogus will never be executed
--- Comment #5 from hubicka at gcc dot gnu dot org 2009-05-09 18:31 ---
Subject: Bug 40082
Author: hubicka
Date: Sat May 9 18:31:32 2009
New Revision: 147319
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147319
Log:
PR bootstrap/40082
* ipa.c
--- Comment #4 from hubicka at gcc dot gnu dot org 2009-05-09 20:10 ---
Subject: Bug 40080
Author: hubicka
Date: Sat May 9 20:10:37 2009
New Revision: 147320
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147320
Log:
PR middle-end/40080
* cgraphunit.c
--- Comment #6 from hubicka at gcc dot gnu dot org 2009-04-06 11:24 ---
Subject: Bug 39659
Author: hubicka
Date: Mon Apr 6 11:24:32 2009
New Revision: 145589
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145589
Log:
PR middle-end/39659
* except.c
--- Comment #4 from hubicka at gcc dot gnu dot org 2009-03-29 13:32 ---
Subject: Bug 28850
Author: hubicka
Date: Sun Mar 29 13:32:13 2009
New Revision: 145233
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145233
Log:
PR middle-end/28850
* tree-pass.h
--- Comment #28 from hubicka at gcc dot gnu dot org 2009-03-29 18:26
---
The testcase is now failing on mainline. Reason seems to be new pure-const
pass causing PRE to take unacceptable amount of time producing extraordinarily
large bitmaps. I stoppped it after while and out of 1GB
--- Comment #29 from hubicka at gcc dot gnu dot org 2009-03-29 18:31
---
tree-ssa-pre.c:4201 (init_pre)68 544319360 2960
2920 35303438
tree-ssa-pre.c:590 (bitmap_set_new) 187851 167503080 38440200
12734360 183944666
tree-ssa-pre.c:591
--- Comment #26 from hubicka at gcc dot gnu dot org 2009-03-29 18:48
---
We seem to have regression at mainline today perhaps because of pure-const
at -O2:
cfg.c:142 (alloc_block)15403008: 2.3% 0:
0.0% 0: 0.0% 0: 0.0% 160448
--- Comment #4 from hubicka at gcc dot gnu dot org 2009-03-08 22:37 ---
Subject: Bug 39361
Author: hubicka
Date: Sun Mar 8 22:37:26 2009
New Revision: 144713
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144713
Log:
PR target/39361
* tree-inline.c
--- Comment #5 from hubicka at gcc dot gnu dot org 2009-03-08 23:10 ---
There is if (optimize) test in inliner to disable copy and constant
propagation. The reason is to preserve debug info, with optimizing we always do
cprop while inlining.
So this patch just enable constant
--- Comment #2 from hubicka at gcc dot gnu dot org 2009-03-05 02:04 ---
I specifically kept the code propagating TREE_READONLY arguments so const
arguments will get constant propagated at -O0. But I see the propagation is
disabled for SSA registers.
I am testing patch for this...
I
--- Comment #6 from hubicka at gcc dot gnu dot org 2009-03-05 02:09 ---
This is curious, since we should see the initializer when adding variable at
first time. I am looking into this.
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39360
--- Comment #3 from hubicka at gcc dot gnu dot org 2009-03-01 11:02 ---
Subject: Bug 39267
Author: hubicka
Date: Sun Mar 1 11:02:30 2009
New Revision: 144515
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144515
Log:
PR debug/39267
* tree-inline.c
--- Comment #4 from hubicka at gcc dot gnu dot org 2009-03-01 18:47 ---
Subject: Bug 39267
Author: hubicka
Date: Sun Mar 1 18:47:08 2009
New Revision: 144529
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144529
Log:
PR debug/39267
* tree.h
--- Comment #2 from hubicka at gcc dot gnu dot org 2009-02-28 21:34 ---
Subject: Bug 39267
Author: hubicka
Date: Sat Feb 28 21:34:23 2009
New Revision: 144496
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144496
Log:
PR debug/39267
* cgraph.h
--- Comment #1 from hubicka at gcc dot gnu dot org 2009-02-27 19:49 ---
Subject: Bug 39267
Author: hubicka
Date: Fri Feb 27 19:49:42 2009
New Revision: 144474
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144474
Log:
PR debug/39267
* tree.h (TREE_PROTECTED): Fix
--- Comment #14 from hubicka at gcc dot gnu dot org 2009-02-23 13:11
---
Subject: Bug 37709
Author: hubicka
Date: Mon Feb 23 13:10:53 2009
New Revision: 144381
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144381
Log:
PR tree-optimization/37709
--- Comment #15 from hubicka at gcc dot gnu dot org 2009-02-23 13:12
---
Fixed.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #44 from hubicka at gcc dot gnu dot org 2009-02-23 13:41
---
Hi,
I believe that using fold_convert instead of fold_build1 means that we would
bypass folding done in fold_unary that handles stuff like two conversions in a
row while fold_convert is primarily about returning
--- Comment #52 from hubicka at gcc dot gnu dot org 2009-02-23 16:06
---
With patches proposed for c/12245 we now need 377MB (from original over 1GB)
garbage and produce 920MB of IL.
Pretty much all the garbage is coming from temporary list constructed here:
/* Add
--- Comment #46 from hubicka at gcc dot gnu dot org 2009-02-23 16:29
---
So with brand new tuplified world, we need new statistics ;)
After parsing we are still the same:
cfg.c:216 (connect_src) 608608: 0.2%520:
0.0%3028808: 1.6% 519680
--- Comment #3 from hubicka at gcc dot gnu dot org 2009-02-23 16:39 ---
Testcase no longer compile:
/home/jh/bitmachine.cc:5049: error: declaration of 'typedef typename
Context::inner_context_type::state_base_type
boost::fsm::simple_stateMostDerived, Context, Reactions, InnerInitial
--- Comment #45 from hubicka at gcc dot gnu dot org 2009-02-23 16:46
---
Subject: Bug 12245
Author: hubicka
Date: Mon Feb 23 16:46:32 2009
New Revision: 144384
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144384
Log:
PR c/12245
* ggc.h (htab_create_ggc): Use
--- Comment #42 from hubicka at gcc dot gnu dot org 2009-02-22 11:21
---
Actual representation of constructor don't seem to be major problem here.
We seem to build _a lot_ (117MB) of CONVERT exprs just to call fold on it and
convert integer to proper type, so counting in INTEGER_CSTs
--- Comment #11 from hubicka at gcc dot gnu dot org 2009-02-22 14:22
---
Created an attachment (id=17340)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17340action=view)
Dump of block structure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37709
--- Comment #12 from hubicka at gcc dot gnu dot org 2009-02-22 14:23
---
Created an attachment (id=17341)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17341action=view)
Little dumping facility
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37709
--- Comment #13 from hubicka at gcc dot gnu dot org 2009-02-22 14:46
---
There are obviously giant trees of blocks that have all variables unused and no
statements in them coming from the early inliner. I am getting convinced we
can safely prune those even at -g3: user can
--- Comment #29 from hubicka at gcc dot gnu dot org 2009-02-22 18:46
---
I mean aligned(64).
I guess something like this then?
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 144373)
+++ config/i386/i386.c
--- Comment #40 from hubicka at gcc dot gnu dot org 2009-02-21 12:40
---
I happen to have compiler with statistics around:
We still need about 400MB, mostly integer constants:
c-decl.c:473 (bind) 125040: 0.0% 0:
0.0% 0: 0.0% 0
--- Comment #26 from hubicka at gcc dot gnu dot org 2009-02-21 13:00
---
I had somehting along this lines in mind:
Index: config/i386/i386.c
===
*** config/i386/i386.c (revision 144352)
--- config/i386/i386.c (working
--- Comment #15 from hubicka at gcc dot gnu dot org 2009-02-12 16:47
---
The DFmode and DImodes are different. Aligning DFmode on stack is very
performance critical, while DImodes on 32bit machine can quite safely be
misaligned (if we ignore their possible use in MMX intrincisc).
I
--- Comment #33 from hubicka at gcc dot gnu dot org 2009-02-08 11:32
---
Partial memory issues are fixed, but I think related to register pressure
awareness of invariant motion we did not change much. Steven, what do you
think?
I can give it another run on 32bit tester.
--
http
--- Comment #46 from hubicka at gcc dot gnu dot org 2009-02-08 11:50
---
With new-RA we seem to do better on this testcase now:
hubi...@occam:~$ time ./a.out-3.4
real0m5.448s
user0m5.440s
sys 0m0.012s
hubi...@occam:~$ time ./a.out
real0m5.834s
user0m5.836s
sys
--- Comment #15 from hubicka at gcc dot gnu dot org 2009-02-08 12:36
---
I tested the patch on SPECfp and core and there is not much difference. I
guess without somehow tweaking regalloc there is not much to do about this
problem. Xuepeng, if the testcase is core2-variant sensitive
--- Comment #16 from hubicka at gcc dot gnu dot org 2009-02-08 12:40
---
Since the splitting peep2 don't seem to be win in general (it wins only when
copy propagation takes place afterwards) and we don't seem to understand what
really makes the testcase faster I am unassigning myself
--- Comment #13 from hubicka at gcc dot gnu dot org 2009-02-06 16:47
---
Subject: Bug 38844
Author: hubicka
Date: Fri Feb 6 16:47:39 2009
New Revision: 143985
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143985
Log:
PR tree-optimization/38844
* ipa-inline.c
--- Comment #14 from hubicka at gcc dot gnu dot org 2009-02-06 16:49
---
Fixed on mainline
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from hubicka at gcc dot gnu dot org 2009-02-02 16:35
---
try_inline should not recurse when edge is already inlined. The following
patch should fix the problem, I will benchmark it tonight
Index: ipa-inline.c
--- Comment #10 from hubicka at gcc dot gnu dot org 2009-01-30 08:00
---
Yes, it is harmless, so P4 should be better match. The test is checking that
loop disambugiation is done one way not the other way while both are correct
choices.
Honza
--
hubicka at gcc dot gnu dot org
--- Comment #3 from hubicka at gcc dot gnu dot org 2009-01-14 20:20 ---
It might be IRA change. Chips generally preffer separate load and execute
instruction as in the old loop over the load+execute since they are easier to
retire.
Splitting the instruction post reload probably won't
--- Comment #4 from hubicka at gcc dot gnu dot org 2009-01-14 20:31 ---
Actually perhaps in simple case like this even peep2 will work since we can
copyprop will fix it later. I am trying to add the peep
--
hubicka at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from hubicka at gcc dot gnu dot org 2009-01-15 00:30 ---
Created an attachment (id=17106)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17106action=view)
Proposed patch
The patch makes GCC to generate movaps load followed by addps. On Core 2 it
speeds up
--- Comment #1 from hubicka at gcc dot gnu dot org 2009-01-06 17:54 ---
Subject: Bug 38744
Author: hubicka
Date: Tue Jan 6 17:54:02 2009
New Revision: 143127
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143127
Log:
PR target/38744
* i386.c (ix86_expand_call
--- Comment #13 from hubicka at gcc dot gnu dot org 2009-01-05 20:01
---
Hi,
sorry for delays, somehow non-tuplified alpha shot this off the todo list.
I still can't build the target:
../../gcc/mips-tfile.c:672:24: error: mips/a.out.h: No such file or directory
../../gcc/mips-tfile.c
--- Comment #12 from hubicka at gcc dot gnu dot org 2008-12-06 08:35
---
Subject: Bug 38074
Author: hubicka
Date: Sat Dec 6 08:34:20 2008
New Revision: 142517
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142517
Log:
PR tree-optimization/38074
* cgraphbuild.c
--- Comment #10 from hubicka at gcc dot gnu dot org 2008-12-05 17:08
---
compute_call_stmt_bb_frequency test is indeed bit insane, but probably works in
practice. I will fix this on pretty-ipa branch.
Looking at sw(__MAIN) just after profiling, profile is there and it is sort of
sane
--- Comment #2 from hubicka at gcc dot gnu dot org 2008-11-17 22:27 ---
Mine.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #7 from hubicka at gcc dot gnu dot org 2008-11-11 20:09 ---
Current implementation of inliner is perfectly unaware of the debug info size
implications. There is alternative to limit number of BLOCKS in function body
growth same way as we limit stack usage that would just add
--- Comment #20 from hubicka at gcc dot gnu dot org 2008-09-26 21:12
---
The testcase now compiles at -O2 in resonable time.
Checking enabled compiler:
CFG verifier : 15.02 ( 5%) usr 0.01 ( 0%) sys 15.13 ( 5%) wall
0 kB ( 0%) ggc
df reaching defs : 7.57 ( 2
--- Comment #21 from hubicka at gcc dot gnu dot org 2008-09-26 22:15
---
I've just tested Kenny's df scan ref union patch. We still have over 2.2GB
footprint that is not that much different from unpatched compiler.
allocpool statistics now give some more useful data:
df_scan_ref base
--- Comment #7 from hubicka at gcc dot gnu dot org 2008-09-26 22:56 ---
Hi,
so to be sure I didn't mess up anything. The following is testcase I use:
typedef struct shared_ptr_struct
{
unsigned long phase:48;
unsigned int thread:16;
void *addr;
} shared_ptr_t;
int y
--- Comment #22 from hubicka at gcc dot gnu dot org 2008-09-26 23:34
---
With Kenny's updated df patch and updated statistics I now get:
Alloc-pool Kind Pools Elt size Allocated (elts) Peak (elts)
Leak (elts
201 - 300 of 631 matches
Mail list logo
