--- Comment #12 from steven at gcc dot gnu dot org 2006-07-16 13:52 ---
The test case in comment #11 looks like a classic store motion opportunity to
me. GCC 3.3 performs the store motion, GCC 4.2 r115467 does not.
Zdenek, I thought tree-ssa-lim should be able to do store motion in
--- Comment #8 from steven at gcc dot gnu dot org 2006-07-16 16:51 ---
No. At -Os, we care about smaller code. Unless that sequence of insns with
muls and shifts is smaller than a div, we should produce the div at -Os. And
as far as I can see, the div will always be smaller.
Not a
--- Comment #9 from steven at gcc dot gnu dot org 2008-11-16 12:17 ---
Advice to folks caring about compiler stability instead of supposedly faster:
Always use double-queue instead of overeager. The overeager solver is just not
reliable enough, and I have never found any proof for the
--- Comment #13 from steven at gcc dot gnu dot org 2008-11-18 21:31 ---
Are things moving forward on the fwprop issue?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from steven at gcc dot gnu dot org 2008-11-18 21:34 ---
P1 bug with a pending patch... maybe a reviewer could take a look at this
(seemingly trivial) patch at
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00180.html
?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #1 from steven at gcc dot gnu dot org 2008-11-21 06:41 ---
*** This bug has been marked as a duplicate of 23286 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from steven at gcc dot gnu dot org 2008-11-21 06:41 ---
*** Bug 38204 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2008-11-21 20:57 ---
This bug is shamefully incomplete. There is no way anyone willing to give this
a look can know what to look for.
For example, a few things one would have to know before he/she can even begin
to consider whether/how
--- Comment #5 from steven at gcc dot gnu dot org 2008-11-21 21:13 ---
What does regmove change, i.e. which of the many things that regmove does, is
helpful for the test case for this PR?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37437
--- Comment #35 from steven at gcc dot gnu dot org 2008-11-21 21:29 ---
So is there a test case with current top-of-trunk that fails? This is marked
as a P1 regression, but IIUC we don't even have a test case, after Jakub's fix
for PR37316 ?
--
http://gcc.gnu.or
--- Comment #7 from steven at gcc dot gnu dot org 2008-11-21 21:54 ---
The reduced test case of comment #3 does not ICE on ia64 for gcc 4.4.0 20081121
(revision 142902).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37716
--- Comment #37 from steven at gcc dot gnu dot org 2008-11-22 09:13 ---
Re: comment #35 and comment #36
That is code hoisting, again. See Bug 23286 and some the bugs closed as a
duplicate of Bug 23286. Looks like it's time to implement tree-level hoisting
:-)
--
steven at gc
--- Comment #5 from steven at gcc dot gnu dot org 2008-11-22 09:51 ---
I created a t.c with both functions in it:
unsigned int f1(unsigned int i, unsigned int n) {++i; if (i == n) ++i; return
i;}
unsigned int f2(unsigned int i, unsigned int n) {++i; i += i == n; return i;}
With
--- Comment #6 from steven at gcc dot gnu dot org 2008-11-22 10:04 ---
Ah, now I see what Pinski meant at comment #2.
Before CSE, we still have the original code for f1:
unsigned int f(unsigned int i, unsigned int n)
{
i.20 = i + 1;
if (i.20 == n) i.20 = i.20 + 1;
return i.20
--- Comment #7 from steven at gcc dot gnu dot org 2008-11-22 10:53 ---
The last time this bug was reconfirmed, was in March 2008. PRE has been
completely rewritten since then. With today's trunk, I still see PRE take most
of the compile time, but it's "only" 20% (
--- Comment #16 from steven at gcc dot gnu dot org 2008-11-22 10:31 ---
See comment #7 and comment #13.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from steven at gcc dot gnu dot org 2008-11-22 11:17 ---
Ping?
Patch exists, tested and all, and just needs a re-test and then submit...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34571
--- Comment #5 from steven at gcc dot gnu dot org 2008-11-22 11:23 ---
passes.texi *does* have documentation for the reassoc pass.
Fixed by dnovillo in r114200:
PR 26242
* doc/passes.texi: Add documentation for pass_vrp, pass_ipa_pta,
pass_fre, pass_store_ccp
--- Comment #10 from steven at gcc dot gnu dot org 2008-11-22 11:36 ---
Trunk today generates the following code (this is the final_cleanup dump):
;; Function foo (foo)
foo ()
{
static char eof_reached = 0;
int bytes;
int toread;
:
toread = 4096;
:
bytes = bar (toread
--- Comment #8 from steven at gcc dot gnu dot org 2008-11-22 11:45 ---
I don't think anyone is interested in fixing this -> WONTFIX.
--
steven at gcc dot gnu dot org changed:
What|Removed
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #5 from steven at gcc dot gnu dot org 2008-11-22 17:44 ---
Is there a mangling convention now for fixed-point types, or not?
If not, we should make this a sorry() and resolve this bug as SUSPENDED for
now.
If there is, well, you know, we should add it ;-)
--
http
--- Comment #3 from steven at gcc dot gnu dot org 2008-11-22 18:20 ---
With a trivial one-liner patch this could look a lot better:
$ ./cc1plus t.C
void foo()
t.C:6: error: no match for 'operator=' in 'a = ({...})'
t.C:1: note: candidates are: A& A::operat
--- Comment #16 from steven at gcc dot gnu dot org 2008-11-23 13:07 ---
Created an attachment (id=16751)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16751&action=view)
Proof-of-concept patch
It is not terribly complicated to add hoisting to tree-ssa-pre.c. I have
attac
--- Comment #17 from steven at gcc dot gnu dot org 2008-11-23 13:11 ---
For the test case of comment #0, the proof-of-concept patch does the following
in the .084t.pre dump (relevant excerpts only):
VBEOUT[2] := { {lshift_expr,a_2(D),1} (0004) }
Inserting expression 5 into AVAIL_OUT
--- Comment #18 from steven at gcc dot gnu dot org 2008-11-23 13:22 ---
The test case of PR38204 shows one of the problems with proof-of-concept patch,
namely the "don't move up too much" problem. The .pre dump looks like this:
test (int a, int b, int c, int g)
{
--- Comment #21 from steven at gcc dot gnu dot org 2008-11-23 14:20 ---
I'll work on something that bootstraps and passes testing. But cost-related
decisions (like the one from comment #20) are not on my TODO list right now.
The pass that should do this is called s
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #23 from steven at gcc dot gnu dot org 2008-11-27 15:26 ---
Created an attachment (id=16784)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16784&action=view)
less unpolished version of tree code hoisting
This fixes some bugs in the proof-of-concept patch:
1
--- Comment #2 from steven at gcc dot gnu dot org 2008-11-28 11:23 ---
There really is obvious way to remove the argument pushes without libcall
notes. There is nothing in the RTL to make clear that the pushes are dead when
the call is removed, so they pushes stay.
There are several
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #3 from steven at gcc dot gnu dot org 2008-11-29 16:25 ---
Is this still an issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26307
--- Comment #5 from steven at gcc dot gnu dot org 2008-11-29 19:28 ---
Can an ARM maintainer please check this bug? Comment #4 suggests this bug is
fixed, but it needs re-checking now that IRA has been merged.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #15 from steven at gcc dot gnu dot org 2008-11-29 22:23 ---
I'm not sure if this bug is fixed, though. -ftrapv is still broken afaik.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19020
--- Comment #1 from steven at gcc dot gnu dot org 2008-11-29 22:42 ---
Looks like something alias related - so CCing Richi.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #26 from steven at gcc dot gnu dot org 2008-11-30 20:45 ---
Resurrecting regmove is not an option. Time is better spent on figuring out
what regmove does, that makes a difference, and see if IRA can be taught to do
the same.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #28 from steven at gcc dot gnu dot org 2008-11-30 21:18 ---
You're not explaining what regmove does. What transformation do these
alternatives with "*" enable regmove to do?
I'm not saying that a separate pass is not an option. Perhaps a regmove-like
pa
--- Comment #29 from steven at gcc dot gnu dot org 2008-11-30 21:32 ---
The insns 8 in comment #0 show the regmove transformation that matters here:
With regmove disabled::
(insn:HI 8 7 14 2 ../../include/mmintrin.h:300 (set (reg:V2SI 61)
(plus:V2SI (reg:V2SI 63 [ x
--- Comment #13 from steven at gcc dot gnu dot org 2008-12-01 12:24 ---
After fixing the issue mentioned in comment#2 and comment #8, gcse.c hoisting
hoists things too far up, e.g.:
{ pred ENTRY }
BB1
if (...) goto BB2 else goto BB3
{ succ BB2, BB3 }
{ pred BB1 }
BB2
...
goto BB4
--- Comment #24 from steven at gcc dot gnu dot org 2008-12-01 22:00 ---
Created an attachment (id=16803)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16803&action=view)
patch to implement code hoisting in tree-ssa-pre.c
This passes bootstrap+testing on ia64-linux and amd6
--- Comment #4 from steven at gcc dot gnu dot org 2008-12-01 22:12 ---
davidxl, my latest patch to bug 23286 (tree-hoist_v3.diff) makes PRE in
tree-ssa-pre.c code-size aware. I have tested this with CSiBE on
mips-unknown-elf.
Without the patch, code size at -Os with PRE enabled is ~17
--- Comment #10 from steven at gcc dot gnu dot org 2008-12-01 23:04 ---
With so many dups, IMHO this ought to be fixed for the releases...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2008-12-03 18:53 ---
You can enable the aliasing warnings (-Wstrict-aliasing=2) and see if there are
warnings when compiling psim.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38387
--- Comment #7 from steven at gcc dot gnu dot org 2008-12-03 19:01 ---
But a regression at least on some targets. Confirmed.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2008-12-04 16:55 ---
Hi Joost,
Thanks for all your hard work, but...
This is just the known problem that -fschedule-insns on x86* heavily constrains
the options for the register allocator. There are many bug reports about this,
most
--- Comment #2 from steven at gcc dot gnu dot org 2008-12-04 16:58 ---
If RTL pre can catch this, then so should tree-PRE without enabling
partial-partial PRE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38401
--- Comment #3 from steven at gcc dot gnu dot org 2008-12-04 17:08 ---
I do not see RTL PRE catch this on ia64, with or without -fgcse-las.
Can you show, please, the RTL dumps before and after GCSE?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38401
--- Comment #5 from steven at gcc dot gnu dot org 2008-12-04 17:27 ---
by_all was there because you made it so on purpose. From tree-ssa-pre.c:
" For the partial anticipation case, we only perform insertion if it
is partially anticipated in some block, and fully available i
--- Comment #8 from steven at gcc dot gnu dot org 2008-12-04 18:16 ---
Created an attachment (id=16828)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16828&action=view)
.gcse1 dump of r142405 on ia64-linux
I still don't see why this is caught on powerpc by RTL PRE
--- Comment #1 from steven at gcc dot gnu dot org 2008-12-04 21:11 ---
*** Bug 38408 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2008-12-04 21:11 ---
*** This bug has been marked as a duplicate of 38406 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2008-12-05 09:15 ---
Is it possible to back-port the fix to GCC 4.3?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38393
--- Comment #10 from steven at gcc dot gnu dot org 2008-12-06 15:37 ---
If the code layout (see comment #2) is indeed causing the slow-down, this
problem might have been fixed along with bug 38074.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
--- Comment #11 from steven at gcc dot gnu dot org 2008-12-06 20:17 ---
Created an attachment (id=16842)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16842&action=view)
Remove overeager solver
Bootstrapped and tested on ia64-unknown-linux-gnu.
Time-tested by compilin
--- Comment #12 from steven at gcc dot gnu dot org 2008-12-06 21:25 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00409.html
Approval mail never made it through, but you can see traces of it here:
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00410.html
--
steven at
--- Comment #11 from steven at gcc dot gnu dot org 2008-12-06 22:05 ---
What's the status of this bug? Fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37948
--- Comment #15 from steven at gcc dot gnu dot org 2008-12-06 22:54 ---
Subject: Bug 36365
Author: steven
Date: Sat Dec 6 22:52:43 2008
New Revision: 142529
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142529
Log:
PR rtl-optimization/36365
* d
--- Comment #14 from steven at gcc dot gnu dot org 2008-12-06 22:54 ---
Fixed in GCC 4.4.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from steven at gcc dot gnu dot org 2008-12-07 11:55 ---
Diego, in comment #7 you said you will work on this...
So? Have you worked on this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33237
--- Comment #1 from steven at gcc dot gnu dot org 2008-12-07 15:28 ---
Learn C, then try again.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2008-12-08 20:06 ---
What is target dependent about this, that you need a target hook for it?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2008-12-08 20:20 ---
Joseph Myers introduced this in the manual with the following patch:
http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00726.html
So this is a regression.
Ah, and Joseph also explained how to fix this, see comment #2
--- Comment #7 from steven at gcc dot gnu dot org 2008-12-08 20:40 ---
Well, I can't even find this paragraph you want to reference.
And I was under the impression that there was a kind-of "you broke it, you fix
it rule" with GCC bugs. Am I wrong or does this just n
--- Comment #9 from steven at gcc dot gnu dot org 2008-12-09 09:00 ---
Something as simple as this would already fix the broken link.
Index: gcc/doc/sourcebuild.texi
===
--- gcc/doc/sourcebuild.texi(revision 142582
--- Comment #4 from steven at gcc dot gnu dot org 2008-12-09 18:53 ---
I have had no trouble bootstrapping 4.4 on ia64-unknown-linux-gnu (Debian) in
the last two weeks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38326
--- Comment #2 from steven at gcc dot gnu dot org 2008-12-09 18:59 ---
This is what -Wshadow is for. We can't invent a new C dialect or "fix" the
standard.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #47 from steven at gcc dot gnu dot org 2008-12-10 11:42 ---
Re. comment #37:
Mark, bug 38453 has a simple test case that shows the poor optimization choice
for ARM-linux. Also, there are now 4 bugs closed as duplicates of this one, so
many users run into this and consider
--- Comment #48 from steven at gcc dot gnu dot org 2008-12-10 11:43 ---
To P3 per comment #37.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #50 from steven at gcc dot gnu dot org 2008-12-10 12:31 ---
The cost check for final value replacement was removed in revision 122896 (from
bug 33419, see http://gcc.gnu.org/viewcvs?view=rev&revision=122896)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
--- Comment #46 from steven at gcc dot gnu dot org 2008-12-10 11:25 ---
*** Bug 38453 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2008-12-10 11:25 ---
*** This bug has been marked as a duplicate of 32044 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #3 from steven at gcc dot gnu dot org 2008-12-10 10:51 ---
Investigating.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #5 from steven at gcc dot gnu dot org 2008-12-10 11:24 ---
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044#c5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38453
--- Comment #55 from steven at gcc dot gnu dot org 2008-12-10 21:27 ---
// This is the test case from PR38453.
// See comment #0 of that bug for further information:
// http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38453#c0
typedef struct
{
int lc;
int pb;
} bar;
void foo(bar
--- Comment #56 from steven at gcc dot gnu dot org 2008-12-10 21:44 ---
Re. comment #52:
I've pasted the test case in the audit trail here as plain text -- it's pretty
small and it shows the problem nicely. The issue is that with -Os, on all
targets, the line,
propsRes-&
--- Comment #1 from steven at gcc dot gnu dot org 2008-12-10 23:09 ---
Seen in r141389
(http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg01966.html)
Not seen anymore in r141405
(http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg02014.html)
HJ, looks fixed to me...?
--
http
--- Comment #30 from steven at gcc dot gnu dot org 2008-12-10 23:18 ---
This one is just dragged along with the Summary changes every time a new GCC is
released. I'd say WONTFIX for this bug. Eric, you would "add a blurb about
that in the platform-specific installation notes
--- Comment #10 from steven at gcc dot gnu dot org 2008-12-11 00:10 ---
Created an attachment (id=16882)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16882&action=view)
proposed patch
Looking for comments in this patch...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25314
--- Comment #60 from steven at gcc dot gnu dot org 2008-12-11 00:27 ---
IMHO I the transformation to division is not fine. I would argue this is the
core issue in this problem report.
You are right that a combination of div and mod is quite common in real-world
code. Right now, GCC
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #63 from steven at gcc dot gnu dot org 2008-12-11 07:03 ---
Re. comment #62:
Transforming the code and adding notes to allow the compiler to undo the
transformation is not an option with the available infrastructure in GCC.
You'd have to add some kind of note (some
--- Comment #15 from steven at gcc dot gnu dot org 2008-12-15 17:38 ---
Re. comment #14: Yes, I suppose so. Why do you want to remove gcse-las from
mainline. Not that I'm against it -- ideally RTL gcse.c would not work on
memory at all anymore -- but I wouldn't remove gcse
--- Comment #12 from steven at gcc dot gnu dot org 2008-12-15 21:17 ---
One of the bottlenecks seems to be find_temp_slot_from_address.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #13 from steven at gcc dot gnu dot org 2008-12-15 21:27 ---
OK, to elaborate: I'm playing with this test case on ia64-linux, and I reduced
the test case by some 8000 lines to make it compilable at all. With this 8000
lines less, it actually spends more time for
--- Comment #14 from steven at gcc dot gnu dot org 2008-12-15 21:53 ---
For the inline heuristics, almost all time is also spent in stack slot related
stuff. The culprit is estimate_stack_frame_size (or actually,
add_alias_set__conflicts) in cfgexpand.c.
(What are we doing in cfgexpand
--- Comment #15 from steven at gcc dot gnu dot org 2008-12-15 21:55 ---
>From cfgexpand.c:
static void
add_alias_set_conflicts (void)
{
size_t i, j, n = stack_vars_num;
for (i = 0; i < n; ++i)
{
tree type_i = TREE_TYPE (stack_vars[i].decl);
bool
--- Comment #16 from steven at gcc dot gnu dot org 2008-12-15 21:56 ---
Oh, and FWIW, for yukawa_gn_full, stack_vars_num == 67551 for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #1 from steven at gcc dot gnu dot org 2008-12-16 06:22 ---
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20468#c1
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #26 from steven at gcc dot gnu dot org 2008-12-16 16:26 ---
I am going to work on the -O0 problems a bit.
The operand scanner is the problem at -O3. Richi, this is one you may want to
try on the alias improvements branch, if most of the time is spent on virtual
SSA names (I
--- Comment #19 from steven at gcc dot gnu dot org 2008-12-16 12:45 ---
Re. comment #18, I'd say "brilliant" if it wasn't such a poor performance :-)
Did you manage to get a time report out of that run?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #12 from steven at gcc dot gnu dot org 2008-12-16 13:45 ---
Looks like something along the lines of gcse.c:can_assign_to_reg_p() is called
for here in replace_read.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922
--- Comment #22 from steven at gcc dot gnu dot org 2008-12-16 13:41 ---
We may be better off with a slightly reduced test case for the -O3 report.
It's not difficult to cut out ~8000 lines (like I did yesterday) and still have
a huge test case (and the horendous compile times
--- Comment #3 from steven at gcc dot gnu dot org 2008-12-16 23:03 ---
This is not fixable. When a bug is filed, messages are sent out and picked up
by archive mirrors. This is desirable for GCC the project but probably less so
for individual GCC users.
--
steven at gcc dot gnu dot
--- Comment #30 from steven at gcc dot gnu dot org 2008-12-17 07:01 ---
I think redoing this with 4.4.0 would be useful, to check if new code (like
IRA) uses this kind of non-linear algorithms. But the register renaming patch
hasn't changed between 4.3 and 4.4, so I would compile
--- Comment #33 from steven at gcc dot gnu dot org 2008-12-17 19:40 ---
cfgexpand.c:defer_stack_allocation() has this gem:
/* Without optimization, *most* variables are allocated from the
stack, which makes the quadratic problem large exactly when we
want compilation to
--- Comment #12 from steven at gcc dot gnu dot org 2008-12-18 16:55 ---
Let me try, I'm kinda sorta responsible for this bug in a way, you know...
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #13 from steven at gcc dot gnu dot org 2008-12-18 21:19 ---
Jakub's idea of comment #10 is nice conceptually, but it's a bit complicated in
practice for most cases where a libcall is emitted. Before subreg lowering we
have this:
(insn 8 7 9 2 t.c:19 (set (mem:D
--- Comment #14 from steven at gcc dot gnu dot org 2008-12-18 22:35 ---
Created an attachment (id=16939)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16939&action=view)
make all functions with nonzero crtl->outgoing_args_size non-leaf
The result of this patch is that D
--- Comment #15 from steven at gcc dot gnu dot org 2008-12-18 22:58 ---
Created an attachment (id=16940)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16940&action=view)
Make targets allocate outgoing args space if necessary
Alternative approach is to let all targets c
101 - 200 of 3051 matches
Mail list logo
