--- Comment #8 from hubicka at gcc dot gnu dot org 2006-11-30 13:06 ---
Probably my bug, I guess the same as shown in dlv nightly tester.
I am looking into it.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from hubicka at gcc dot gnu dot org 2006-11-30 19:36 ---
Subject: Bug 30028
Author: hubicka
Date: Thu Nov 30 19:36:02 2006
New Revision: 119375
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119375
Log:
PR middle-end/30028
* builtins.c
--- Comment #11 from hubicka at gcc dot gnu dot org 2006-10-18 21:54
---
Patch for non-unit-at-a-time comitted now.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from hubicka at gcc dot gnu dot org 2006-10-15 19:46 ---
Subject: Bug 29241
Author: hubicka
Date: Sun Oct 15 19:46:26 2006
New Revision: 117753
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117753
Log:
PR middle-end/29241
* cgraphunit.c
--- Comment #4 from hubicka at gcc dot gnu dot org 2006-10-13 07:42 ---
Subject: Bug 28419
Author: hubicka
Date: Fri Oct 13 07:41:53 2006
New Revision: 117684
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117684
Log:
PR c/28419
* c-decl.c (c_make_fname_decl): Do
--- Comment #5 from hubicka at gcc dot gnu dot org 2006-10-13 07:42 ---
Fixed in mainline.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from hubicka at gcc dot gnu dot org 2006-10-09 16:06 ---
Mine.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #52 from hubicka at gcc dot gnu dot org 2006-09-12 10:11
---
Subject: Bug 28071
Author: hubicka
Date: Tue Sep 12 10:11:04 2006
New Revision: 116886
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116886
Log:
PR rtl-optimization/28071
* tree-vect
--- Comment #19 from hubicka at gcc dot gnu dot org 2006-08-24 13:30
---
Subject: Bug 26881
Author: hubicka
Date: Thu Aug 24 13:30:45 2006
New Revision: 116374
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116374
Log:
PR debug/26881
* cgraph.c: Fix comments
--- Comment #11 from hubicka at gcc dot gnu dot org 2006-08-21 12:44
---
Just to note that for simple accestors (optimizing to single move), the
compiler should be smart enough to figure out that inlining always reduce code
size and inlining those will never hit any of the parameters
--- Comment #8 from hubicka at gcc dot gnu dot org 2006-08-20 18:47 ---
Subject: Bug 28779
Author: hubicka
Date: Sun Aug 20 18:46:54 2006
New Revision: 116274
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116274
Log:
PR middle-end/28779
* ipa-inline.c
--- Comment #42 from hubicka at gcc dot gnu dot org 2006-08-21 00:00
---
Subject: Bug 28071
Author: hubicka
Date: Mon Aug 21 00:00:14 2006
New Revision: 116277
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116277
Log:
PR rtl-optimization/28071
* reload1.c
--- Comment #43 from hubicka at gcc dot gnu dot org 2006-08-21 01:42
---
Subject: Bug 28071
Author: hubicka
Date: Mon Aug 21 01:42:39 2006
New Revision: 116284
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116284
Log:
PR rtl-optimization/28071
* tree-optimize.c
--- Comment #7 from hubicka at gcc dot gnu dot org 2006-08-19 21:25 ---
mine bug...
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #9 from hubicka at gcc dot gnu dot org 2006-08-17 09:44 ---
Subject: Bug 27865
Author: hubicka
Date: Thu Aug 17 09:44:12 2006
New Revision: 116220
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116220
Log:
PR tree-optimization/27865
* reload1.c
--- Comment #46 from hubicka at gcc dot gnu dot org 2006-08-08 06:15
---
In x86/x86-64 world one can be almost sure that the load+execute instruction
pair will execute (marginaly to noticeably) faster than move+load-and-execute
instruction pair as the more complex instructions
--- Comment #4 from hubicka at gcc dot gnu dot org 2006-08-08 06:35 ---
The strlen inlining depends on the -mtune switch. -mtune=athlon,generic and
i686
unrolls the strlen by in-line loop, while -mtune=pentium4 use the rep
operation.
Would be possible to benchmark both -mtune=generic
--- Comment #14 from hubicka at gcc dot gnu dot org 2006-08-07 08:01
---
Created an attachment (id=12032)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12032action=view)
Patch in testing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26881
--- Comment #40 from hubicka at gcc dot gnu dot org 2006-08-07 08:18
---
Roger,
the patch for advance loc seems sane solution to me (in my limited
understanding
of dwarf2).
If I understand it right, we need the advance_loc only when crossing the
section boundary, so we ought
--- Comment #5 from hubicka at gcc dot gnu dot org 2006-08-07 09:09 ---
The IA-64 problem shall be fixed by my patch for PR target/26655.
The x86 problem is trickier. Reload is decided to merge all classes mentioned
in given alternative, so ad is equivalent to A, while recog.c
--- Comment #3 from hubicka at gcc dot gnu dot org 2006-08-07 10:18 ---
Hi,
because of quite serve register pressure issues, I don't like much idea of GCC
realocating stack transparently (it is also dificult to teach reload to decide
when alignment is needed). Safe bugfix for 4.2 seems
--- Comment #3 from hubicka at gcc dot gnu dot org 2006-08-07 11:59 ---
Created an attachment (id=12037)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12037action=view)
patch
It looks like we should bite the bullet and let cgraph code to output the debug
info I am testing
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #5 from hubicka at gcc dot gnu dot org 2006-08-04 17:03 ---
Subject: Bug 24888
Author: hubicka
Date: Fri Aug 4 17:03:32 2006
New Revision: 115927
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115927
Log:
PR tree-optimization/24888
* tree-inline.c
--- Comment #13 from hubicka at gcc dot gnu dot org 2006-08-04 17:05
---
Subject: Bug 26655
Author: hubicka
Date: Fri Aug 4 17:05:38 2006
New Revision: 115928
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115928
Log:
PR target/26655
PR target/28270
--- Comment #3 from hubicka at gcc dot gnu dot org 2006-08-04 17:05 ---
Subject: Bug 28270
Author: hubicka
Date: Fri Aug 4 17:05:38 2006
New Revision: 115928
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115928
Log:
PR target/26655
PR target/28270
--- Comment #33 from hubicka at gcc dot gnu dot org 2006-07-29 13:14
---
Subject: Bug 28071
Author: hubicka
Date: Sat Jul 29 13:14:22 2006
New Revision: 115810
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115810
Log:
PR rtl-optimization/28071
* cfgrtl.c
--- Comment #28 from hubicka at gcc dot gnu dot org 2006-07-27 16:02
---
Subject: Bug 28071
Author: hubicka
Date: Thu Jul 27 16:02:27 2006
New Revision: 115776
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115776
Log:
PR rtl-optimization/28071
* global.c
--- Comment #29 from hubicka at gcc dot gnu dot org 2006-07-27 16:03
---
Subject: Bug 28071
Author: hubicka
Date: Thu Jul 27 16:03:22 2006
New Revision: 115777
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115777
Log:
PR rtl-optimization/28071
* cselib.c
--- Comment #30 from hubicka at gcc dot gnu dot org 2006-07-27 17:10
---
Subject: Bug 28071
Author: hubicka
Date: Thu Jul 27 17:10:07 2006
New Revision: 115779
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115779
Log:
PR rtl-optimization/28071
* hashtab.c
--- Comment #28 from hubicka at gcc dot gnu dot org 2006-07-26 20:17
---
Subject: Bug 27882
Author: hubicka
Date: Wed Jul 26 20:17:32 2006
New Revision: 115763
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115763
Log:
PR tree-optimization/27882
* cgraph.c
--- Comment #23 from hubicka at gcc dot gnu dot org 2006-07-26 22:52
---
Subject: Bug 28071
Author: hubicka
Date: Wed Jul 26 22:51:56 2006
New Revision: 115765
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115765
Log:
PR rtl-optimization/28071
* regmove.c
--- Comment #19 from hubicka at gcc dot gnu dot org 2006-07-24 11:24
---
Subject: Bug 28071
Author: hubicka
Date: Mon Jul 24 11:23:21 2006
New Revision: 115712
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115712
Log:
PR rtl-optimization/28071
* ipa-inline.c
--- Comment #20 from hubicka at gcc dot gnu dot org 2006-07-24 11:28
---
Subject: Bug 28071
Author: hubicka
Date: Mon Jul 24 11:27:53 2006
New Revision: 115713
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115713
Log:
PR rtl-optimization/28071
* tree-cfg.c
--- Comment #21 from hubicka at gcc dot gnu dot org 2006-07-24 11:54
---
OK, some summary ;)
Mainline (after the first three patches) at -O now peaks 450MB (just because of
register allocator's conflict matrix, otherwise it is about 150MB). Still not
quite icc's 12 seconds/200MB
--- Comment #2 from hubicka at gcc dot gnu dot org 2006-07-24 00:16 ---
Subject: Bug 25795
Author: hubicka
Date: Mon Jul 24 00:16:16 2006
New Revision: 115693
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115693
Log:
PR c/25795
PR c++/27369
* cgraph.c
--- Comment #15 from hubicka at gcc dot gnu dot org 2006-07-24 00:16
---
Subject: Bug 27369
Author: hubicka
Date: Mon Jul 24 00:16:16 2006
New Revision: 115693
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115693
Log:
PR c/25795
PR c++/27369
* cgraph.c
--- Comment #13 from hubicka at gcc dot gnu dot org 2006-07-22 12:42
---
Is this bug to be closed then?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28075
--- Comment #3 from hubicka at gcc dot gnu dot org 2006-07-22 13:28 ---
Testing patch
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #11 from hubicka at gcc dot gnu dot org 2006-07-21 17:07
---
Unless reg-stack is told how to reschedule the instructions to match register
stack constraints, I don't think we can get much closer to solving the problem
that some instruction orderings needs a lot more fxchs
--- Comment #1 from hubicka at gcc dot gnu dot org 2006-07-21 19:31 ---
Testing patch.
Honza
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from hubicka at gcc dot gnu dot org 2006-07-21 20:24 ---
*** This bug has been marked as a duplicate of 26655 ***
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from hubicka at gcc dot gnu dot org 2006-07-21 20:24
---
*** Bug 28270 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26655
--- Comment #12 from hubicka at gcc dot gnu dot org 2006-07-21 20:25
---
Testing patch.
Honza
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from hubicka at gcc dot gnu dot org 2006-07-21 20:36 ---
cgraph_analyze_function is reentrant for non-unit-at-a-time support. However
with unit-at-a-time, the analysis happens only after unit has been finalized
and at that time frontend is not supposed to come up
--- Comment #8 from hubicka at gcc dot gnu dot org 2006-07-21 21:11 ---
Hmm,
the function fi contains 3 calls, many of called functions contains further
calls.
Since our metric allows to replace each call by up to 10 instructions and we
allow fi to grow twice, we can end up
--- Comment #26 from hubicka at gcc dot gnu dot org 2006-07-19 17:29
---
Well, I don't like much the limiting of inlining in recursive functions (where
it is rather interesting)
and I can't convince myself that the second patch is safe (ie the cycle don't
have to be in consetuctive
--- Comment #17 from hubicka at gcc dot gnu dot org 2006-07-02 13:13
---
Increasing alignment of static variable during tree optimization should be as
easy as increasing the DECL_ALIGN. All variables are output after all
functions.
Honza
--
http://gcc.gnu.org/bugzilla
--- Comment #13 from hubicka at gcc dot gnu dot org 2006-05-09 11:59
---
The simplified testcase seems to be solved now (on mainline and Athlon):
[EMAIL PROTECTED]:/aux/hubicka/gcc/build/gcc$ gcc-2.95 -O3 t.C -march=i686
[EMAIL PROTECTED]:/aux/hubicka/gcc/build/gcc$ ./a.out
[EMAIL
--- Comment #11 from hubicka at gcc dot gnu dot org 2006-05-09 19:19
---
Fixed in mainline by patch
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00315.html
(I got the PR number wrong, sorry).
It fixes the functions only, variables still can be optimized out. Do we wish
to do the same
--- Comment #7 from hubicka at gcc dot gnu dot org 2006-05-08 21:42 ---
Subject: Bug 25962
Author: hubicka
Date: Mon May 8 21:42:17 2006
New Revision: 113633
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113633
Log:
PR middle-end/25962
* cgraphunit.c
--- Comment #5 from hubicka at gcc dot gnu dot org 2006-05-04 12:43 ---
Subject: Bug 25962
Author: hubicka
Date: Thu May 4 12:42:55 2006
New Revision: 113522
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113522
Log:
PR middle-end/25962
* cgraphunit.c
--- Comment #9 from hubicka at gcc dot gnu dot org 2006-04-30 13:27 ---
Both patches (comment #7 and comment #8) are OK assuming they pass testing
(that is rather obvious).
Thanks,
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25776
--- Comment #6 from hubicka at gcc dot gnu dot org 2006-04-30 13:33 ---
This is probably won't fix as well. The problem is that calls to builtins in
general can be produced arbitrarily late in the compilation process (before RTL
expansion).
We might try to do limited inliner pass
--- Comment #7 from hubicka at gcc dot gnu dot org 2006-04-30 13:35 ---
I should probably also note that IPA branch will get it right in the testcase
(and the other PR) via early inlining, but it sadly won't get it right in any
consistent manner...
Honza
--
http://gcc.gnu.org
--- Comment #2 from hubicka at gcc dot gnu dot org 2006-04-30 13:45 ---
Good point, I think I can do that easilly once mainline reopens.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from hubicka at gcc dot gnu dot org 2006-04-30 13:48 ---
testing patch.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #9 from hubicka at gcc dot gnu dot org 2006-04-30 13:56 ---
Concerning the comments, unit-at-a-time is not optimization, it is just way
overall compilation is driven.
I don't quite see reason for outputting unneeded static functions even at -O0
that it mostly just slows down
--- Comment #6 from hubicka at gcc dot gnu dot org 2006-04-30 14:24 ---
Sorry, I've must missed the two pings and noticed the problem only now while
housekeeping.
There is no easy way to peek cfglayout about what decisions it will do in
future, so there is no easy
way to decide whether
--- Comment #8 from hubicka at gcc dot gnu dot org 2006-04-30 14:30 ---
Jakub,
adding a worklist and passing all variables to dwarf2out as last it quite easy
to do. However could you enlighten me a bit why the particular order is
needed?
Honza
--
hubicka at gcc dot gnu dot org
--- Comment #12 from hubicka at gcc dot gnu dot org 2006-04-06 20:33
---
Subject: Bug 20815
Author: hubicka
Date: Thu Apr 6 20:33:21 2006
New Revision: 112738
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112738
Log:
PR profile/20815
PR profile/26399
--- Comment #5 from hubicka at gcc dot gnu dot org 2006-04-06 20:33 ---
Subject: Bug 26399
Author: hubicka
Date: Thu Apr 6 20:33:21 2006
New Revision: 112738
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112738
Log:
PR profile/20815
PR profile/26399
--- Comment #11 from hubicka at gcc dot gnu dot org 2006-01-23 15:27
---
This might be another manifestation of the argument saving area with
-maccumulate-outgoing-args
(if it is so, either -fno-tree-ter or -mno-accumulate-outgoing-args should
solve it). I will try to look
--- Comment #10 from hubicka at gcc dot gnu dot org 2006-01-19 00:14
---
My understanding of C type based aliasing rules always was that char, as an
exception, might alias with everything. Perhaps I lived in false belief for a
while, but at least -Wstrict-aliasing seems to think so
--- Comment #12 from hubicka at gcc dot gnu dot org 2006-01-19 00:38
---
Right, forgot about that... At the moment I can't think of testcase that would
break the transitivity without use of unions...
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25654
--- Comment #26 from hubicka at gcc dot gnu dot org 2006-01-17 21:07
---
Hi,
I've looked into it for some time, so here is my POV of this ugly issue.
It seems to me that from documentation of EMPTY_FIELD_BOUNDARY in gccint it is
clear that it
should be ignored when
--- Comment #7 from hubicka at gcc dot gnu dot org 2006-01-16 14:56 ---
These two testcases seems to still fail for me even with the patch. (I use b.c
-mpreferred-stack-boundary=2 -S -march=i686 -frename-registers)
extern void abort (void) __attribute__((noreturn));
struct setconflict
--- Comment #5 from hubicka at gcc dot gnu dot org 2006-01-11 13:26 ---
Subject: Bug 25042
Author: hubicka
Date: Wed Jan 11 13:26:45 2006
New Revision: 109582
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109582
Log:
PR target/25042
* i386.c
--- Comment #6 from hubicka at gcc dot gnu dot org 2006-01-11 13:32 ---
Subject: Bug 25042
Author: hubicka
Date: Wed Jan 11 13:32:44 2006
New Revision: 109583
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109583
Log:
PR target/25042
* i386.c
--- Comment #3 from hubicka at gcc dot gnu dot org 2005-12-19 23:11 ---
testing patch:
Index: config/i386/i386.c
===
*** config/i386/i386.c (revision 108753)
--- config/i386/i386.c (working copy
--- Comment #5 from hubicka at gcc dot gnu dot org 2005-12-18 14:51 ---
Subject: Bug 25224
Author: hubicka
Date: Sun Dec 18 14:51:53 2005
New Revision: 108754
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108754
Log:
PR rtl-optimization/25224
* tree-ssa-loop
--- Comment #5 from hubicka at gcc dot gnu dot org 2005-12-18 20:53 ---
Simplified testcase seems to work for me on 4.1 branch:
restore_fpu:
movl4(%esp), %edx
movlboot_cpu_data+12, %eax
testl $16777216, %eax
je .L2
jmp foo
.L2
--- Comment #12 from hubicka at gcc dot gnu dot org 2005-12-15 12:49
---
Subject: Bug 24969
Author: hubicka
Date: Thu Dec 15 12:49:10 2005
New Revision: 108573
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108573
Log:
PR target/24969
* i386.c (classify_argument
--- Comment #13 from hubicka at gcc dot gnu dot org 2005-12-15 13:48
---
Subject: Bug 24969
Author: hubicka
Date: Thu Dec 15 13:48:22 2005
New Revision: 108577
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108577
Log:
PR target/24969
* i386.c (classify_argument
--- Comment #15 from hubicka at gcc dot gnu dot org 2005-12-15 19:04
---
Subject: Bug 24969
Author: hubicka
Date: Thu Dec 15 19:04:04 2005
New Revision: 108592
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108592
Log:
PR target/24969
* i386.c (classify_argument
--- Comment #3 from hubicka at gcc dot gnu dot org 2005-12-15 23:52 ---
Subject: Bug 25224
Author: hubicka
Date: Thu Dec 15 23:52:16 2005
New Revision: 108606
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108606
Log:
PR rtl-optimization/25224
* tree-ssa-loop
--- Comment #10 from hubicka at gcc dot gnu dot org 2005-12-02 18:14
---
Testing patch:
2005-12-02 Jan Hubicka [EMAIL PROTECTED]
PR target/24969
* i386.c (classify_argument): Properly adjust offset of bitfield for
substructures.
Index: config/i386/i386.c
--- Comment #2 from hubicka at gcc dot gnu dot org 2005-12-02 18:21 ---
testing patch:
2005-12-02 Jan Hubicka [EMAIL PROTECTED]
* tree-ssa-loop-unswitch.c (tree_unswitch_single_loop): Free copy
tables.
Index: tree-ssa-loop-unswitch.c
--- Comment #10 from hubicka at gcc dot gnu dot org 2005-11-22 16:56
---
Subject: Bug 24653
Author: hubicka
Date: Tue Nov 22 16:56:48 2005
New Revision: 107365
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107365
Log:
PR tree-optimization/24653
* tree-ssa-ccp.c
--- Comment #7 from hubicka at gcc dot gnu dot org 2005-11-21 13:14 ---
Subject: Bug 24653
Author: hubicka
Date: Mon Nov 21 13:14:02 2005
New Revision: 107304
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107304
Log:
PR tree-optimization/24653
* tree-ssa-ccp.c
--- Comment #12 from hubicka at gcc dot gnu dot org 2005-11-05 00:55
---
Subject: Bug 23490
Author: hubicka
Date: Sat Nov 5 00:55:23 2005
New Revision: 106520
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106520
Log:
PR rtl-optimization/23490
* doc/invoke.texi
--- Comment #8 from hubicka at gcc dot gnu dot org 2005-11-03 08:22 ---
no longer 4.1 regression.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hubicka at gcc dot gnu dot org
GCC build triplet: x86_64-gnu-linux
GCC host triplet: x86_64-gnu-linux
GCC target triplet: x86_64-gnu-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24653
--- Comment #1 from hubicka at gcc dot gnu dot org 2005-11-03 11:40 ---
Actually I cutpasted wrong BB and the -fno-tree-sra on 4.0 makes the
difference go away, so ignore the huge dumps :)
Let me see if I can work out something better.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #2 from hubicka at gcc dot gnu dot org 2005-11-03 12:58 ---
OK, have new, 100% sure theory ;)
for 4.0 -fno-tree-sra makes important difference, for 4.1 it does not. One
difference is that 4.0 splits startingpoint:
Initial instantiation for startPoint
startPoint.e[2
--- Comment #5 from hubicka at gcc dot gnu dot org 2005-11-03 19:38 ---
This is ineed move-loop-invariants bug. It assumes that destination of memory
store can be changed to register without validating
that is not the case on i386 - you can write arbitrary floating point value
--- Comment #2 from hubicka at gcc dot gnu dot org 2005-11-03 19:46 ---
SUBROUTINE FOO
WRITE(6,*) ''
END
balli:/usr/src/gcctest/install/gcc-base/bin # ./gfortran a.F90 -mcmodel=medium
-O1 -S
balli:/usr/src/gcctest/install/gcc-base/bin #
--
hubicka at gcc dot gnu dot org changed
--- Comment #9 from hubicka at gcc dot gnu dot org 2005-11-03 20:06 ---
For reload CSE there is --param max-cselib-memory-locations=10
that cuts it's time to 1%, overall.
Since this testcase is sort of designed to excercise the worst case behaviour,
I think it is not too bad...
alias
--- Comment #12 from hubicka at gcc dot gnu dot org 2005-11-03 20:19
---
It seems to me that really only solution is working load PRE on TREEs. Since
this is out of 4.1
reach we can either revert my patch or retarget this for 4.2. I must say I am
inclined
to the second - the patch
--- 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 #8 from hubicka at gcc dot gnu dot org 2005-11-03 22:54 ---
Actually the code 4.1 in comment #5 should execute faster on true i686. It is
longer and will trigger partial memory stalls on later chips.
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22563
--- Comment #8 from hubicka at gcc dot gnu dot org 2005-11-02 23:21 ---
Subject: Bug 23303
Author: hubicka
Date: Wed Nov 2 23:21:22 2005
New Revision: 106406
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106406
Log:
PR target/23303
* i386.md: Add peep2
--- Comment #9 from hubicka at gcc dot gnu dot org 2005-11-02 23:21 ---
Fixed in mainline now.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from hubicka at gcc dot gnu dot org 2005-10-31 14:49 ---
Subject: Bug 24487
Author: hubicka
Date: Mon Oct 31 14:48:57 2005
New Revision: 106276
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106276
Log:
PR profile/24487
* predict.c (predict_loops
--- Comment #7 from hubicka at gcc dot gnu dot org 2005-10-31 14:54 ---
Concerning Mark's comment (I noticed only after committing the patch). I am not
sure what exactly Mark has in mind - this situation is not actually dependend
on inlining - easilly
we might just have funcition
--- Comment #6 from hubicka at gcc dot gnu dot org 2005-10-31 18:15 ---
Actually the cited 4.0 sequence do not obey the const int x86_read_modify =
~(m_PENT | m_PPRO);
setting -march=athlon or using -Os makes the move go away. Additionally I get
following sequence out of 4.0 in SUSE
--- Comment #6 from hubicka at gcc dot gnu dot org 2005-10-31 18:24 ---
I don't have P4 to test handy. Can you re-test whether fixing 23302 (23303 is
invalid) make any difference?
I doubt these two make actual runtime changes - the sequence would translate to
same uops for P4
--- Comment #28 from hubicka at gcc dot gnu dot org 2005-10-31 18:36
---
I get 0m8.052s on 3.4 and 0m8.127s on mainline on Athlon. This hardly counts
as an regression.
This is actually effect of some cost tweaks we did relatie to gimplifier a
while ago.
Reduced testcase fits in limits
--- Comment #20 from hubicka at gcc dot gnu dot org 2005-10-31 18:45
---
Patch comitted. For some reason don't seem to appear in logs?
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from hubicka at gcc dot gnu dot org 2005-10-31 18:47
---
I tested only simplified testcase, but the issue should be resolved pretty
safely.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
501 - 600 of 631 matches
Mail list logo
