--- 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;
--- 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_sca
--- 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 #15 from hubicka at gcc dot gnu dot org 2008-09-19 06:22
---
The infinite loop in ipa-reference is solved now. Is the sixtrack problem
remaining and if so, would be possible to test the proposed patch?
We probably could track it as independent PR and close this one.
Honza
--- Comment #18 from hubicka at gcc dot gnu dot org 2008-09-18 21:11
---
Hi,
some stats on instruction counts and references Kenny asked about:
At -O2:
[EMAIL PROTECTED]:~/gcc-baseline/build-ada/prev-gcc$ grep "(insn"
e.i.157r.outof_cfglayout | wc -l
307811
[EMAIL PROTEC
--- Comment #17 from hubicka at gcc dot gnu dot org 2008-09-18 18:18
---
Subject: Bug 37448
Author: hubicka
Date: Thu Sep 18 18:16:45 2008
New Revision: 140465
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140465
Log:
PR middle-end/37448
* ipa-ref
--- Comment #16 from hubicka at gcc dot gnu dot org 2008-09-18 17:30
---
Subject: Bug 37448
Author: hubicka
Date: Thu Sep 18 17:28:40 2008
New Revision: 140463
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140463
Log:
PR middle-end/37448
* ipa-ref
--- Comment #15 from hubicka at gcc dot gnu dot org 2008-09-18 16:49
---
We seem to make nice progress on the testcase ;)
Conversion to FUD would probably help here, but looking at the DF dumps, the
testcase don't look like your average testcase showing DU/UD chain explosion.
--- Comment #37 from hubicka at gcc dot gnu dot org 2008-09-17 15:02
---
Subject: Bug 18071
Author: hubicka
Date: Wed Sep 17 15:00:59 2008
New Revision: 140418
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140418
Log:
PR c++/18071
* tree.h (DEC
--- Comment #14 from hubicka at gcc dot gnu dot org 2008-09-14 14:31
---
On cross from today tree it seems fine:
Starting program: /home/jh/gcc-baseline/build-aix/gcc/cc1plus -O2 *.ii
-fpreprocessed -quiet -dumpbase makeChemkinReactions.C -maix32 -auxbase
makeChemkinReactions -Wall
--- Comment #9 from hubicka at gcc dot gnu dot org 2008-09-13 22:38 ---
Fixed by my patch.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from hubicka at gcc dot gnu dot org 2008-09-13 22:29 ---
Yes, it is almost definitly same problem.
Honza
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from hubicka at gcc dot gnu dot org 2008-09-13 21:42 ---
It also might be miscompilation of the first stage. profiledbootstrap is using
the stage1 compiler to build all stages and really expect things like 64bit
HOST_WIDE_INT.
Would be possible to re-try this on current
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-09-13 21:41
---
Subject: Bug 32581
Author: hubicka
Date: Sat Sep 13 21:39:44 2008
New Revision: 140349
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140349
Log:
PR middle-end/32581
* tree-p
--- Comment #10 from hubicka at gcc dot gnu dot org 2008-09-13 21:40
---
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 2008-09-13 14:39 ---
Subject: Bug 37392
Author: hubicka
Date: Sat Sep 13 14:38:10 2008
New Revision: 140342
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140342
Log:
PR tree-optimization/37392
* tree-
--- Comment #7 from hubicka at gcc dot gnu dot org 2008-09-13 08:01 ---
Fixed by my patch.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from hubicka at gcc dot gnu dot org 2008-09-13 07:31 ---
Subject: Bug 37500
Author: hubicka
Date: Sat Sep 13 07:30:15 2008
New Revision: 140334
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140334
Log:
PR middle-end/37500
* pt.c (tsubst_d
--- Comment #7 from hubicka at gcc dot gnu dot org 2008-09-12 09:52 ---
Testing patch..
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #14 from hubicka at gcc dot gnu dot org 2008-09-12 08:39
---
Created an attachment (id=16301)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16301&action=view)
patch that should fix the sixtrack problem.
This patch should solve the sixtrack problem. Can you
--- Comment #13 from hubicka at gcc dot gnu dot org 2008-09-12 08:33
---
Having testcase would be great. In theory removing unused things from debug
info should not make any difference. Perhaps it is related to stack frame
packing, that is only other place walking blocks.
could you
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-09-11 12:40
---
Subject: Bug 37448
Author: hubicka
Date: Thu Sep 11 12:38:57 2008
New Revision: 140284
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140284
Log:
PR middle-end/37448
*
--- Comment #10 from hubicka at gcc dot gnu dot org 2008-09-11 12:36
---
Subject: Bug 37448
Author: hubicka
Date: Thu Sep 11 12:34:53 2008
New Revision: 140281
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140281
Log:
PR middle-end/37448
* tree-
--- Comment #2 from hubicka at gcc dot gnu dot org 2008-09-10 12:14 ---
The testcase no longer compiles on mainline for me because of syntax errors.
WOuld be possible to test newer compiler or have updated testcase?
Honza
--
hubicka at gcc dot gnu dot org changed:
What
--- Comment #8 from hubicka at gcc dot gnu dot org 2008-09-10 11:39 ---
And at -O0 we still need about 2GB (because of dataflow leaks?), otherwise we
seem fine compilation time wise
garbage collection: 0.92 ( 3%) usr 0.00 ( 0%) sys 0.93 ( 3%) wall
0 kB ( 0%) ggc
--- Comment #7 from hubicka at gcc dot gnu dot org 2008-09-10 11:32 ---
#0 0x0099c80d in ira_allocno_live_ranges_intersect_p (a1=0x33da8ae0,
a2=0x34395120) at ../../gcc/ira-conflicts.c:535
#1 0x0099ff0e in coalesced_allocno_conflict_p (a1=0x34e221b0,
a2=0x33da8ae0
--- Comment #6 from hubicka at gcc dot gnu dot org 2008-09-10 10:02 ---
Now we spend eons in walking lexical blocks, since add_lexical_block called by
inliner walks till end of the chain.
Is the order of blocks important at all? (i.e. we don't insert them to proper
place anyway,
--- Comment #5 from hubicka at gcc dot gnu dot org 2008-09-10 09:57 ---
With ENABLE_CHECKING we spend ages checking that there are no duplicated edges
in callgraph. Will fix it shortly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
--- Comment #2 from hubicka at gcc dot gnu dot org 2008-09-09 12:54 ---
Quite obviously :(
I will need some asistance here as I don't have HP-PA system and don't know
much about ISA either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
--- Comment #8 from hubicka at gcc dot gnu dot org 2008-09-09 12:47 ---
Created an attachment (id=16263)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16263&action=view)
patch in testing
OK,
I think the problem is that regimplify expect the statement to be already
i
--- Comment #7 from hubicka at gcc dot gnu dot org 2008-09-09 12:37 ---
Jakub,
disabling the regimplification introduced here
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00500.html
fixes the testcase. Since you invented the regimplify function, could you take
a look, please
--- Comment #6 from hubicka at gcc dot gnu dot org 2008-09-09 12:23 ---
This also breaks because of gimple_regimplify_operands
Breakpoint 3, gimple_regimplify_operands (stmt=0x2af5b100,
gsi_p=0x7fffe3b0) at ../../gcc/gimplify.c:7374
7374 push_gimplify_context (&gctx);
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-09-06 20:23
---
The code quality problems are solved. Not closing the bug until IPA-reference
is fixed.
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14703
--- Comment #10 from hubicka at gcc dot gnu dot org 2008-09-06 17:11
---
Subject: Bug 14703
Author: hubicka
Date: Sat Sep 6 17:10:00 2008
New Revision: 140068
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140068
Log:
PR tree-optimization/14703
*
--- Comment #45 from hubicka at gcc dot gnu dot org 2008-09-06 14:12
---
Memory footprint in TOP is about 430MB (64bit machine).
On current mainline we need 191MB before IPA. Top consumers
cfg.c:226 (connect_dest) 598696: 0.2% 180224:
0.5%3484960
--- Comment #4 from hubicka at gcc dot gnu dot org 2008-09-06 13:50 ---
The frontend handling was removed in GCC-4.4 by my patches.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from hubicka at gcc dot gnu dot org 2008-09-06 12:56 ---
cp/lex.c:590 (copy_decl) 10176: 0.0% 0:
0.0% 578168: 0.0% 66200: 0.0% 2257
cp/lex.c:510 (build_lang_decl) 161064: 0.1% 73304:
0.0
--- Comment #8 from hubicka at gcc dot gnu dot org 2008-09-06 12:37 ---
Hi,
the following patch fixes inlining problem:
Index: passes.c
===
--- passes.c(revision 139985)
+++ passes.c(working copy)
@@ -565,6 +565,7
--- Comment #2 from hubicka at gcc dot gnu dot org 2008-09-06 12:09 ---
We eliminate functions, but we never re-scan program to see if the function has
no longer address taken.
To implement this we will need to add to cgraph list of functions/variables
taking address of each function
--- Comment #27 from hubicka at gcc dot gnu dot org 2008-09-06 12:02
---
Also just noticed that offline copy of longest-match get extra move:
.L15:
movzbl 2(%eax), %edi #, tmp87
leal2(%eax), %ecx #, scan.158
movl%edi, %edx # tmp87
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-09-06 12:02
---
Also just noticed that offline copy of longest-match get extra move:
.L15:
movzbl 2(%eax), %edi #, tmp87
leal2(%eax), %ecx #, scan.158
movl%edi, %edx # tmp87
--- Comment #26 from hubicka at gcc dot gnu dot org 2008-09-06 12:00
---
IRA seems to fix the remaining problem with spill in internal loop on 32bit
nicely, so we produce good scores for gzip compared to older GCC versions.
http://gcc.opensuse.org/SPEC-britten/CINT/sandbox-britten
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32913
--- Comment #4 from hubicka at gcc dot gnu dot org 2008-09-04 10:52 ---
Ugly -fPIC friendly workaround would be to add runtime initialization. I.E.
if (!initialized)
{populate my array; initialized = true;}
that would still allow conversion to happen and generate better code than
--- Comment #6 from hubicka at gcc dot gnu dot org 2008-09-04 10:47 ---
Subject: Bug 37343
Author: hubicka
Date: Thu Sep 4 10:45:57 2008
New Revision: 139983
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139983
Log:
PR middle-end/37343
* tre
--- Comment #5 from hubicka at gcc dot gnu dot org 2008-09-04 10:38 ---
FIxed.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from hubicka at gcc dot gnu dot org 2008-09-04 10:37 ---
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 2008-09-04 10:37 ---
Fixed by my patch
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from hubicka at gcc dot gnu dot org 2008-09-04 10:31 ---
Subject: Bug 37358
Author: hubicka
Date: Thu Sep 4 10:30:26 2008
New Revision: 139980
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139980
Log:
PR tree-optimization/37345
--- Comment #4 from hubicka at gcc dot gnu dot org 2008-09-04 10:31 ---
Subject: Bug 37357
Author: hubicka
Date: Thu Sep 4 10:30:26 2008
New Revision: 139980
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139980
Log:
PR tree-optimization/37345
--- Comment #7 from hubicka at gcc dot gnu dot org 2008-09-04 10:31 ---
Subject: Bug 37345
Author: hubicka
Date: Thu Sep 4 10:30:26 2008
New Revision: 139980
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139980
Log:
PR tree-optimization/37345
--- Comment #3 from hubicka at gcc dot gnu dot org 2008-09-03 19:39 ---
I need approval for that :) I've just finished testing and send it to
gcc-patches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37358
--- Comment #1 from hubicka at gcc dot gnu dot org 2008-09-03 19:31 ---
Probably also fixed by fix for PR37345 (or it does not reproduce for me)
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from hubicka at gcc dot gnu dot org 2008-09-03 19:29 ---
This is fixed by patch for PR tree-optimimization/37345
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from hubicka at gcc dot gnu dot org 2008-09-03 18:17 ---
Subject: Bug 37315
Author: hubicka
Date: Wed Sep 3 18:16:26 2008
New Revision: 139945
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139945
Log:
PR tree-optimization/37315
*
--- Comment #1 from hubicka at gcc dot gnu dot org 2008-09-02 18:36 ---
I get 0m9.829s for non-profiled run and 0m9.801s for profiled run, so things
seems to be in order on mainline. I would be curious if there are still some
profile generate/use related regressions on polyhedron
--- Comment #2 from hubicka at gcc dot gnu dot org 2008-08-29 14:58 ---
Subject: Bug 37278
Author: hubicka
Date: Fri Aug 29 14:57:20 2008
New Revision: 139768
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139768
Log:
PR middle-end/37278
* p
--- Comment #6 from hubicka at gcc dot gnu dot org 2008-08-23 20:03 ---
Subject: Bug 37094
Author: hubicka
Date: Sat Aug 23 20:02:08 2008
New Revision: 139522
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139522
Log:
PR target/37094
--- Comment #4 from hubicka at gcc dot gnu dot org 2008-08-21 15:13 ---
Created an attachment (id=16121)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16121&action=view)
Following patch should fix it, I will test it ASAP
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37094
--- Comment #6 from hubicka at gcc dot gnu dot org 2008-08-07 14:56 ---
Subject: Bug 37048
Author: hubicka
Date: Thu Aug 7 14:55:32 2008
New Revision: 138841
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138841
Log:
PR target/37048
* i386.md (single
--- Comment #2 from hubicka at gcc dot gnu dot org 2008-07-31 14:44 ---
Richard, there is one problem that is "yours". We conclude that call is
uninlinable due to type missmatch. This should not happen on C++.
This gets misdiagnozed as originally recursive inlning was only
--- Comment #3 from hubicka at gcc dot gnu dot org 2008-07-18 17:00 ---
I believe this is the same issue as for Darwin that was fixed shortly after
GCCsummit. I am going to build cross to double check.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36574
--- Comment #3 from hubicka at gcc dot gnu dot org 2008-07-16 23:14 ---
Fix comitted.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #3 from hubicka at gcc dot gnu dot org 2008-06-15 22:49 ---
Patch posted.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35853
--- Comment #2 from hubicka at gcc dot gnu dot org 2008-05-06 08:00 ---
Subject: Bug 36118
Author: hubicka
Date: Tue May 6 07:59:54 2008
New Revision: 134975
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134975
Log:
PR tree-optimization/36118
*
--- Comment #6 from hubicka at gcc dot gnu dot org 2008-05-02 13:06 ---
I believe those issues are fixed now. Can someone please confirm it?
(I've managed to swap two versions of patches and commit development version of
it)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36102
--- Comment #3 from hubicka at gcc dot gnu dot org 2008-05-02 11:09 ---
Subject: Bug 36100
Author: hubicka
Date: Fri May 2 11:08:22 2008
New Revision: 134885
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134885
Log:
PR bootstrap/36100
* ipa-
--- Comment #20 from hubicka at gcc dot gnu dot org 2008-04-29 15:40
---
Created an attachment (id=15546)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15546&action=view)
New patch
Hi,
this patch implements idea of having temporary read-only register with
REG_EQUIV no
--- Comment #9 from hubicka at gcc dot gnu dot org 2008-04-25 23:15 ---
Subject: Bug 35843
Author: hubicka
Date: Fri Apr 25 23:14:40 2008
New Revision: 134682
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134682
Log:
PR testsuite/35843
* cfg
--- Comment #19 from hubicka at gcc dot gnu dot org 2008-04-24 16:05
---
I am going to make patch that will with preserve-stack attribute in addition to
inhibitting libcall also put REG_EQUIV notes on a copy instead of argument
register itself that should be sufficient to prevent
--- Comment #5 from hubicka at gcc dot gnu dot org 2008-04-01 08:41 ---
Subject: Bug 35781
Author: hubicka
Date: Tue Apr 1 08:41:14 2008
New Revision: 133786
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133786
Log:
PR middle-end/35781
* m3
--- Comment #5 from hubicka at gcc dot gnu dot org 2008-03-19 14:25 ---
Dump letters removed.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from hubicka at gcc dot gnu dot org 2008-03-19 11:23 ---
Subject: Bug 35094
Author: hubicka
Date: Wed Mar 19 11:22:40 2008
New Revision: 133342
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133342
Log:
* gcc.dg/20050811-2.c: Update dumpi
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-03-03 16:21
---
Subject: Bug 35262
Author: hubicka
Date: Mon Mar 3 16:20:31 2008
New Revision: 132838
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132838
Log:
PR c++/35262
* ipa-
--- Comment #12 from hubicka at gcc dot gnu dot org 2008-03-03 16:23
---
Fixed.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #23 from hubicka at gcc dot gnu dot org 2008-02-26 09:31
---
I guess we need
1) Get the patch to check overwritability of body to mainline and branch, since
it is quite wrong to optimize based on knowledge of body that might be replaced
2) Figure out how to get Apple&#
--- Comment #15 from hubicka at gcc dot gnu dot org 2008-02-23 18:10
---
Still, can I ask how does the PLT entry of Darwin look like? It seems a bit
weird that recursive call that should not trigger lazy binding will get into
code relying on the alignment.
Or are some kind of aliases
--- Comment #14 from hubicka at gcc dot gnu dot org 2008-02-23 18:05
---
I see. It is quite pity that Darwin's dynamic linker insist on the alignment.
I guess it would be worthwhile to try to tell GCC to optimize those calls as
local: calling overhead of recursive functions is
--- Comment #10 from hubicka at gcc dot gnu dot org 2008-02-23 12:57
---
Hi,
as I added to the gcc-patches thread, I think GCC is valid to optimize stack
alignment on the reduced testcase and it is precisely what is supposed to be
done by the code Michael disabled. ABI is not strict
--- Comment #7 from hubicka at gcc dot gnu dot org 2008-02-19 17:11 ---
Subject: Bug 34408
Author: hubicka
Date: Tue Feb 19 17:11:12 2008
New Revision: 132440
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132440
Log:
PR rtl-optimization/34408
--- Comment #14 from hubicka at gcc dot gnu dot org 2008-02-19 17:10
---
Subject: Bug 28779
Author: hubicka
Date: Tue Feb 19 17:09:42 2008
New Revision: 132439
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132439
Log:
PR middle-end/28779
* tree-
--- Comment #13 from hubicka at gcc dot gnu dot org 2008-02-17 20:32
---
Patch posted.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28779
--- Comment #6 from hubicka at gcc dot gnu dot org 2008-02-17 19:45 ---
OK, I am switching it to new again ;)
However the warning really means that GCC decided to not inline the function
because it thinks it is not profitable because it concluded that the call is
infrequent. Perhaps
--- Comment #2 from hubicka at gcc dot gnu dot org 2008-02-17 19:37 ---
I think this is feature. If users explicitely declares as inline, then we do
that, otherwise we doesn't:
/* Don't auto-inline anything that might not be bound within
this unit of translation. */
--- Comment #6 from hubicka at gcc dot gnu dot org 2008-02-17 19:30 ---
Path posted.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #3 from hubicka at gcc dot gnu dot org 2008-02-17 18:37 ---
Since 4.3, noinline is now handled completely by cgraph as inlining decisions
goes.
C and C++ still have duplicated logic on merging declarations, but I am not
duplicate_decl expert, so I am leaving this last bit to
--- Comment #10 from hubicka at gcc dot gnu dot org 2008-02-15 11:55
---
Seems like it. After fwprop1 iter_1 and iter_7 conflict:
D.2095_6 = &iter_1(ab)->D.2086;
iter_7(ab) = iter_1(ab) + 8;
__comp_ctor (&D.2138, D.2094_5);
# SUCC: 4 [100.0%] (fallthru,exec) 5
--- Comment #10 from hubicka at gcc dot gnu dot org 2008-02-15 11:16
---
Subject: Bug 35149
Author: hubicka
Date: Fri Feb 15 11:15:48 2008
New Revision: 132337
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132337
Log:
PR middle-end/35149
--- Comment #9 from hubicka at gcc dot gnu dot org 2008-02-15 11:15 ---
Fixed by my patch.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from hubicka at gcc dot gnu dot org 2008-02-14 15:54 ---
I am going to take a look. Where we split the edge?
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35182
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-02-13 18:15
---
I must say that I don't see it that safe: we can't clone the functions because
at the time fronend decide to rewrite the body by new one we are not having
functions gimplified yet. (well we can clone, b
--- Comment #7 from hubicka at gcc dot gnu dot org 2008-02-13 17:29 ---
This one liner actually took me a while. It is quite ugly ordering issue.
Index: ipa.c
===
--- ipa.c (revision 132243)
+++ ipa.c (working
--- Comment #6 from hubicka at gcc dot gnu dot org 2008-02-13 13:26 ---
I am looking into it. Obviously cgraph is out of sync for whatever reason.
Honza
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #30 from hubicka at gcc dot gnu dot org 2008-02-11 09:23
---
On britten there is also no noticeable effect on SPECfp score.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23322
--- Comment #25 from hubicka at gcc dot gnu dot org 2008-02-08 15:39
---
-fno-tree-dominator-opts -fno-tree-copyrename solves the coalescing problem
(name is introduced by second, the actual problematic pattern by first pass),
saving roughly 1s at both -O2 and 2s at -O3, -O3 is still
--- Comment #24 from hubicka at gcc dot gnu dot org 2008-02-08 15:11
---
Hi,
the tonight runs with continue heuristics shows again improvements on 64bit
scores , but degradation on 32bit scores. Looking into the loop, the real
trouble seems to be that the main loop has 6 loop carried
--- Comment #29 from hubicka at gcc dot gnu dot org 2008-02-08 14:54
---
Hi,
tonight results from Haydn shows 32bit scores with the loop-invariant hack
disabled.
http://www.suse.de/~gcctest/SPEC/CFP/sb-haydn-head-64-32o-32bit/index.html
There are no off noise speedups though I must
--- Comment #1 from hubicka at gcc dot gnu dot org 2008-02-07 16:36 ---
This is fixed by the call frequency patch on mainline.
.L2:
cvtsi2ss(%ebx,%eax,4), %xmm0
addl$1, %eax
cmpl$1000, %eax
mulss %xmm2, %xmm0
addss %xmm0, %xmm1
--- Comment #23 from hubicka at gcc dot gnu dot org 2008-02-07 12:30
---
Created an attachment (id=15115)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15115&action=view)
Annotated profile
I am attaching dump with profile read in. It shows the hot spots in
longest_m
--- Comment #22 from hubicka at gcc dot gnu dot org 2008-02-06 19:22
---
Yes, there are number of unlucky variables. However the real source is here
seems to be always wrong profile guiding regalloc to optimize for cold portions
of the function rather than real increase of register
301 - 400 of 636 matches
Mail list logo
