--- Comment #3 from amylaar at gcc dot gnu dot org 2006-04-12 13:46 ---
sh64 has indexed addressing, but the addition is always done as 64 bit,
and there are currently no implemenmtations that allow the 64 bit logical
address space to be re-mapped into a 32 physical address space
--- Comment #5 from amylaar at gcc dot gnu dot org 2006-04-12 19:59 ---
Created an attachment (id=11251)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11251&action=view)
proposed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27117
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-04-12 20:09 ---
Subject: Bug 27060
Author: amylaar
Date: Wed Apr 12 20:09:41 2006
New Revision: 112898
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112898
Log:
2006-04-12 J"orn Rennecke <[EMAIL PROTECT
--- Comment #7 from amylaar at gcc dot gnu dot org 2006-04-13 11:45 ---
(In reply to comment #6)
> > -#define INDEX_REG_CLASS \
> > - (!ALLOW_INDEXED_ADDRESS ? NO_REGS : TARGET_SHMEDIA ? GENERAL_REGS :
> > R0_REGS)
> > +#define INDEX_REG_CLASS_FOR_MODE(MODE) \
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-04-19 19:35 ---
(In reply to comment #2)
> I'd like to add Joern to the CC list.
>
> I've looked the rtl dumps for the testcase. It seems that
> the wrong code is generated during the peephole2 optimizati
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27226
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-04-20 15:58 ---
This worked in 3.5.0 20040512 (experimental), but failed in 3.5.0 20040630
(experimental)
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-04-20 18:05 ---
(In reply to comment #2)
> You might want to dive into builtins.c:get_pointer_alignment.
>
Hmm, indeed, I see that in 3.5.0 20040512, expand_builtin_memcpy
has found a dest_align of 32 and proceeded to
--- Comment #4 from amylaar at gcc dot gnu dot org 2006-04-20 18:10 ---
Created an attachment (id=11304)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11304&action=view)
proposed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27226
--- Comment #5 from amylaar at gcc dot gnu dot org 2006-04-20 18:58 ---
(In reply to comment #4)
> Created an attachment (id=11304)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11304&action=view) [edit]
> proposed patch
>
Needs some more work.
--
ht
--- Comment #6 from amylaar at gcc dot gnu dot org 2006-04-20 20:38 ---
Created an attachment (id=11305)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11305&action=view)
proposed patch for 4.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27226
--- Comment #8 from amylaar at gcc dot gnu dot org 2006-04-20 21:09 ---
(In reply to comment #7)
> I suggest you test on an architecture that traps on unaligned accesses, so as
> ia64 with the correct prctrl setup.
I don't have access to an ia64 host, but sh-elf is a STRIC
--- Comment #10 from amylaar at gcc dot gnu dot org 2006-04-27 15:35
---
(In reply to comment #6)
> Created an attachment (id=11305)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11305&action=view) [edit]
> proposed patch for 4.1
>
The assignment
i
MED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27394
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-05-02 17:53 ---
In 3.x, double -> char/int conversion was done consistently with the documented
behaviour of integer -> signed integer type conversion.
http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Integers-implementatio
--- Comment #5 from amylaar at gcc dot gnu dot org 2006-05-02 18:21 ---
(In reply to comment #4)
> (In reply to comment #1)
> > In 3.x, double -> char/int conversion was done consistently with the
> > documented
> > behaviour of integer -> signed intege
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-05-08 19:44 ---
(In reply to comment #0)
> It seems that this move insn is generated at loop-invariant.c:
> move_invariant_reg().
Yes. In general, we say that we don't want such SUBREGS to appear in the
first place,
--- Comment #12 from amylaar at gcc dot gnu dot org 2006-05-08 21:09
---
(In reply to comment #11)
> The patch looks good - are you going to test and submit it?
I hope so, however at the moment I have trouble with newlib. The autoconf
upgrade seems rather half-baked at the mom
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27574
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-05-12 16:58 ---
Created an attachment (id=11447)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11447&action=view)
test case
Compiled for either sh-elf or i686-pc-linux-gnu, currrent mainline cc1plus does
not gener
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-05-12 17:02 ---
Created an attachment (id=11448)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11448&action=view)
With the translation result for this file, the testcase can be linked
This file provides a definition
words: build
Severity: blocker
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC target triplet: sh-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27850
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-06-01 15:23 ---
(In reply to comment #1)
> --with-headers with a combined build is not really a good thing.
>
--with-headers is required for cross compilers in order to build a working
libgcov. A working libgcov is requir
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-06-02 23:50 ---
Subject: Bug 27850
Author: amylaar
Date: Fri Jun 2 23:50:11 2006
New Revision: 114332
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114332
Log:
PR other/27850
* Makefile.in (stm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC target triplet: sh-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27906
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-06-05 21:46 ---
Created an attachment (id=11599)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11599&action=view)
testcase (preprocessed __udivmoddi4 source)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27906
-optimization, link-failure
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC target triplet: sh-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28014
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-06-13 15:21 ---
Created an attachment (id=11661)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11661&action=view)
test case
This testcase goes in testsuite/g++.dg/eh .
--
amylaar at gcc dot gnu dot org
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-06-13 17:45 ---
Subject: Bug 28014
Author: amylaar
Date: Tue Jun 13 17:44:56 2006
New Revision: 114616
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114616
Log:
PR target/28014:
gcc:
* con
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-06-13 18:05 ---
Fixed.
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
optimizations require hash collisions
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28123
--- Comment #5 from amylaar at gcc dot gnu dot org 2006-06-22 15:36 ---
(In reply to comment #2)
> You're meant to use contrib/gcc_update to adjust the timestamps.
>
I see nothing in our download or testing documentation suggesting that that
is required after a clean s
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code, EH
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC target triplet: sh-elf
http
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-06-22 15:52 ---
Created an attachment (id=11730)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11730&action=view)
test case
This test case should go in testsuite/g++.dg/eh .
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #4 from amylaar at gcc dot gnu dot org 2006-06-22 16:55 ---
(In reply to comment #2)
> Hmm, I just get an error on a 64bit target so the testcase is at least invalid
> for them:
> t.c:19: error: cast from 'int*' to 'int' loses precision
>
Y
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC target triplet: sh-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28140
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-06-22 19:43 ---
Created an attachment (id=11731)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11731&action=view)
test case
This test case should fail to assemble. Yet it does at -O1 or higher.
--
http://gcc.
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-06-22 21:22 ---
(In reply to comment #2)
> __asm__ ("choke_me %0 %1 %2" : "+m" (*p1), "+m" (*p2), "+m" (*p3));
> *p1 = val0;
> *p2 = val0;
> *p3 = val0;
--- Comment #5 from amylaar at gcc dot gnu dot org 2006-06-22 22:16 ---
Created an attachment (id=11732)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11732&action=view)
patch
I'm currently testing this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28139
ava
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-06-23 17:55 ---
Created an attachment (id=11733)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11733&action=view)
patch
I'm currently testing this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28144
--- Comment #7 from amylaar at gcc dot gnu dot org 2006-07-03 16:39 ---
The keyword description says that the "alias" keyword is specific to missed
optimizations due to aliasing issues.
If that is true, than adding this keyword here was incorrect. If that isn't
true, t
ther
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28251
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-07-04 21:24 ---
Created an attachment (id=11818)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11818&action=view)
Tentative patch
I'm currently testing this patch. Hopefully this will allow to pinpoint the
insns
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-07-04 22:50 ---
Created an attachment (id=11819)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11819&action=view)
Tentative patch
This one compiles...
--
amylaar at gcc dot gnu dot org changed:
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-07-05 13:42 ---
Created an attachment (id=11833)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11833&action=view)
dump diff for mainline r115174 bootstrap failure
The diff with -fdump-noaddr is indeed much more us
y: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28274
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28289
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-07-06 19:08 ---
This patch has added code that is nonsentical when the operation can be
synthesized cheaply in a narrower mode:
r83956 | sayle | 2004-07-01 05:27:09 +0100 (Thu, 01 Jul 2004) | 6 lines
* expmed.c
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-07-06 19:30 ---
When I disable the offending code (by altering add_cost[DImode] at the right
moment), I get the right result for little endian. However, compiling for
big endian gives wrong code:
_expand64:
mov #0,r5
--- Comment #4 from amylaar at gcc dot gnu dot org 2006-07-06 19:32 ---
(In reply to comment #2)
> Investigating... I suspect that the SH backend's rtx_costs are parameterized
> incorrectly, such that a 64-bit shift by the constant 32, looks to be at least
> 32 times
--- Comment #7 from amylaar at gcc dot gnu dot org 2006-07-07 13:50 ---
(In reply to comment #3)
> When I disable the offending code (by altering add_cost[DImode] at the right
> moment), I get the right result for little endian. However, compiling for
> big endian gives w
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-07-07 16:47 ---
(In reply to comment #1)
> testcase?
>
I couldn't find one yet. I suspect this is hidden by tree-optimizers and
missed
optimization issues.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28289
itted.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-07-07 16:54 ---
Created an attachment (id=11850)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11850&action=view)
test case
The available source code for the functions allows the compiler to
see that the called functi
--- Comment #4 from amylaar at gcc dot gnu dot org 2006-07-11 17:23 ---
Created an attachment (id=11860)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11860&action=view)
patch with test case & unroller fix
I've added a testcase, and it showed failures due
--- Comment #6 from amylaar at gcc dot gnu dot org 2006-07-17 14:44 ---
Subject: Bug 28251
Author: amylaar
Date: Mon Jul 17 14:44:48 2006
New Revision: 115519
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115519
Log:
gcc:
PR other/28251
* tree.h (d
--- Comment #7 from amylaar at gcc dot gnu dot org 2006-07-17 16:00 ---
Fixed in mainline.
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38267
: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38391
: missed-optimization
Severity: major
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arc-elf32
http://gcc.gnu.org
--- Comment #1 from amylaar at gcc dot gnu dot org 2008-12-07 21:38 ---
Created an attachment (id=16845)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16845&action=view)
test case
This is the test case, the preprocessed libgcc2 bcmp code. I've used the
version from
--- Comment #2 from amylaar at gcc dot gnu dot org 2008-12-07 21:41 ---
Created an attachment (id=16846)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16846&action=view)
gcc 4.2.1 compiled code
This is the testcase compiled with the options -O2 -mA7, using gcc 4.2.1
w
--- Comment #3 from amylaar at gcc dot gnu dot org 2008-12-07 21:51 ---
Created an attachment (id=16848)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16848&action=view)
gcc 4.4.0 compiled code
This is the testcase compiled using the options -O2 -mA7 with gcc 4.4.0
2
ilure
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38449
--- Comment #2 from amylaar at gcc dot gnu dot org 2008-12-08 20:36 ---
(In reply to comment #1)
> What is target dependent about this, that you need a target hook for it?
Some jumps are OK to be made section crossing, while others are not.
And which ones are OK also depends on tar
account
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: minor
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc
--- Comment #30 from amylaar at gcc dot gnu dot org 2008-12-09 18:22
---
I think the testcase pr27574.C should be added to the testsuite before
closing this bug.
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #31 from amylaar at gcc dot gnu dot org 2008-12-09 18:48
---
Sorry, I only checked for the presence of the original testcase name in
the testsuite, and thus missed the fact that there is a new test called
local-var-in-contructor.C [sic] .
--
amylaar at gcc dot gnu dot
--- Comment #4 from amylaar at gcc dot gnu dot org 2008-12-09 21:13 ---
The .083t.cunroll (gcc 4.2.1) and .1045.cunroll (gcc 4.4.0) dumps
show that the read memory read pointers are incremented as given in the
source.
This is still the case in the .085.ivopts dump from gcc 4.2.1, but no
--- Comment #5 from amylaar at gcc dot gnu dot org 2008-12-09 21:52 ---
FWIW, the same problem can be seen for the SH, although it doesn't manifest
as an actual preformance regression from 4.2.1 because the 4.2.1 SH backend is
suboptimal - the mov.b / extu.b scheduling is bad,
--- Comment #42 from amylaar at gcc dot gnu dot org 2008-12-10 04:29
---
(In reply to comment #25)
> Created an attachment (id=14637)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14637&action=view) [edit]
> Patch to make ivopts take autoincrement addressing modes
--- Comment #43 from amylaar at gcc dot gnu dot org 2008-12-10 05:29
---
(In reply to comment #25)
> Created an attachment (id=14637)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14637&action=view) [edit]
> Patch to make ivopts take autoincrement addressing modes
--- Comment #7 from amylaar at gcc dot gnu dot org 2008-12-10 05:40 ---
(In reply to comment #6)
> This is most likely a duplicate of bug 31849. IV-opts does not understand at
> all auto-increment/decrement.
I see little in common with the original subject of PR31849 (th
--- Comment #45 from amylaar at gcc dot gnu dot org 2008-12-11 02:07
---
(In reply to comment #44)
> Subject: Re: [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts
> not understanding autoincrement)
>
> Joern, can you attach the updated patch?
I st
--- Comment #2 from amylaar at gcc dot gnu dot org 2008-12-27 12:16 ---
(In reply to comment #1)
> Is there a test case which shows the wrong-code
> behavior, and which can be checked against the
> new register allocator?
I don't know of any particular test case. If y
--- Comment #4 from amylaar at gcc dot gnu dot org 2008-12-28 22:07 ---
(In reply to comment #3)
> Is this still an issue with current trunk, or
> with 4.3?
I had a look at the current trunk and the diffs leading up to it, and I can
confirm that the issue has not been fixed.
Howe
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38758
C bitmnp01
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
http://gcc.gnu.or
--- Comment #2 from amylaar at gcc dot gnu dot org 2009-01-09 16:39 ---
(In reply to comment #1)
> Testcase?
Unfortunately, the EEMBC benchmarks are not freely redistributable.
See http://www.eembc.org .
I'm not sure yet which parts of the benchmark are intrinsic to the pro
--- Comment #3 from amylaar at gcc dot gnu dot org 2009-01-09 17:34 ---
(In reply to comment #1)
> Testcase?
Ok, I now have a testcase that is almost, but not quite, entirely unlike
fbital. About the only characteristic it shares with fbital is that it has
a loop which provi
--- Comment #6 from amylaar at gcc dot gnu dot org 2009-01-10 16:10 ---
(In reply to comment #5)
> Joern, re. comment #4, Richi refers to my patch to enable PRE at -Os, see
> [1].
> An extension to this patch that we tested on x86 machines, is to disable PRE
> for sc
--- Comment #18 from amylaar at gcc dot gnu dot org 2009-01-12 18:09
---
(In reply to comment #17)
> I think enabling partial PRE to do it is appropriate (with at most inserting
> on one edge).
I think the abstraction with tree-ssa and cfglayout mode has gone too far.
We no
--- Comment #20 from amylaar at gcc dot gnu dot org 2009-01-13 14:00
---
(In reply to comment #19)
> Joern, nobody is forcing you to follow the crowd if you think the crowd is
> going in the wrong direction.
I have evidence that the direction is wrong. I added a new option to d
--- Comment #21 from amylaar at gcc dot gnu dot org 2009-01-13 14:11
---
(In reply to comment #20)
> office: 1.39% worse
Actually, this is the EEMBC version with bezier01, where the entire benchmark
gets optized away and thus tiny changes in the cost of the set-up code m
--- Comment #23 from amylaar at gcc dot gnu dot org 2009-01-13 14:58
---
(In reply to comment #22)
> If you post a patch to add the option to enable/disable partial-PRE I will
> happily review and approve it for 4.4.
I'd be happy to post the patch, but we (ARC) are still
--- Comment #9 from amylaar at gcc dot gnu dot org 2009-01-14 18:47 ---
I think the disregard for conditional execution opportunities and the
assumption that phi nodes have no execution cost are two separate issues.
I'd like to address the latter first, because it causes expone
--- Comment #11 from amylaar at gcc dot gnu dot org 2009-01-14 22:06
---
(In reply to comment #10)
> You would completely underestimate the optimization opportunities PRE
> unleashes.
Well, at least for partial-partial-RE, as mentioned before in PR38401,
benchmarks indicate tha
--- Comment #12 from amylaar at gcc dot gnu dot org 2009-01-15 11:36
---
(In reply to comment #11)
P.S.:
Another feature that we could look at is the number of times an input
ssa name is used. If it is used more than once, we cannot rely on the
original ssa name to go away, and hence
--- Comment #15 from amylaar at gcc dot gnu dot org 2009-06-17 04:20
---
The problem was due to USEs of SYMBOL_REFs that were emitted by the target
code.
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from amylaar at gcc dot gnu dot org 2009-06-17 04:27
---
Subject: Bug 39254
Author: amylaar
Date: Wed Jun 17 04:27:29 2009
New Revision: 148568
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148568
Log:
PR target/39254
* config/rs6000/
--- Comment #17 from amylaar at gcc dot gnu dot org 2009-06-17 04:37
---
I have applied the patch to the trunk. Should I apply it to the 4.4 release
branch as well?
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from amylaar at gcc dot gnu dot org 2009-07-16 00:11 ---
(In reply to comment #3)
> Hi Steven,
>
> Maybe I'm missing something, but what do patches talking about
> SMALL_REGISTER_CLASSES have to do with this issue? For ARM, the registers
> involved
.4.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40817
--- Comment #25 from amylaar at gcc dot gnu dot org 2009-07-30 23:30
---
(In reply to comment #24)
> Unfortunately, there is still no word from the FSF on what they did with our
> Copyright Assignment.
As already mentioned in PR 38785, I've posted the patch here:
http://gcc
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
http://gcc.gnu.org
--- Comment #2 from amylaar at gcc dot gnu dot org 2005-11-09 18:59 ---
Created an attachment (id=10191)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10191&action=view)
test case
Mainline version 106440 configured for i686-pc-linux-gnu --with-arch=i686:
../../i686/
--- Comment #3 from amylaar at gcc dot gnu dot org 2005-11-09 19:08 ---
Created an attachment (id=10192)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10192&action=view)
test case
This is a shorter test case, but only debug information changes were observed
for this te
--- Comment #4 from amylaar at gcc dot gnu dot org 2005-11-09 19:35 ---
I have observed the -quiet influence only with a proprietary testcase so far
(EEMBC aiifft01/bmark.c for sh-elf -m4 -ml -g -O3 -version -fomit-frame-pointer
-funroll-loops --param max-inline-insns-single=5
1 - 100 of 799 matches
Mail list logo
