AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42226
--- Comment #1 from carrot at google dot com 2009-11-30 08:56 ---
Created an attachment (id=19184)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19184&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42226
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i
--- Comment #1 from carrot at google dot com 2009-12-01 09:01 ---
Created an attachment (id=19194)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19194&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42235
--- Comment #3 from carrot at google dot com 2009-12-02 07:00 ---
> Could you do some more analysis of where this is coming from using rtl / tree
> dumps ?
>
Everything in tree dump is normal.
After rtl expand, every parameter is loaded into a pseudo register at the ent
ter?
--
Summary: redundant register move around mul instruction
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42258
--- Comment #4 from carrot at google dot com 2009-12-07 08:58 ---
Created an attachment (id=19247)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19247&action=view)
patch
The attached patch can fix this bug. But due to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42258, i
--- Comment #1 from carrot at google dot com 2009-12-09 02:27 ---
Gcc 4.4 doesn't have this problem. It is a new regression caused by patch
152533.
--
carrot at google dot com changed:
What|Removed |
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42351
--- Comment #7 from carrot at google dot com 2009-12-11 07:54 ---
(In reply to comment #6)
> (In reply to comment #5)
>
> > Please submit patches to gcc-patc...@gcc.gnu.org rather than attaching it to
> > the bug report.
>
> Also when doing so can you measure
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC
--- Comment #1 from carrot at google dot com 2009-12-24 01:47 ---
Created an attachment (id=19381)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19381&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42486
: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42495
--- Comment #1 from carrot at google dot com 2009-12-25 07:51 ---
Created an attachment (id=19388)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19388&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42495
--- Comment #2 from carrot at google dot com 2009-12-25 07:52 ---
> instruction. It uses the same number of instructions. -Os should do the same
It uses the same number of registers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42495
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42496
--- Comment #1 from carrot at google dot com 2009-12-25 08:14 ---
Created an attachment (id=19389)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19389&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42496
Compile following code with options -march=armv5te -O2
extern void *memcpy(void *dst, const void *src, int n);
void *memmove(void *dst, const void *src, int n)
{
const char *p = src;
char *q = dst;
if (__builtin_expect(q < p, 1)) {
return memcpy(dst, src, n);
} else {
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42498
signedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42500
--- Comment #3 from carrot at google dot com 2009-12-30 06:46 ---
My complete command line:
"/home/carrot/compiler/armobj/gcc/cc1plus" "-fpreprocessed" "testH.ii" "-quiet"
"-dumpbase" "testH.cpp" "-auxbase-strip"
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target trip
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet
--- Comment #10 from carrot at google dot com 2010-01-11 06:47 ---
(In reply to comment #9)
> With "GCC: (GNU) 4.5.0 20100108 (experimental) [trunk revision 155731]" and my
> patch for bug 20070 applied, I get the following code:
>
> iterate:
> push
--- Comment #12 from carrot at google dot com 2010-01-11 08:55 ---
(In reply to comment #11)
> Yes, I would have expected the block starting with .L4 to be *after*
> the block starting with .L5, something like so:
>
> iterate:
> push{lr}
> ldr
get
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42835
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42879
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42895
--- Comment #1 from carrot at google dot com 2010-01-29 00:14 ---
Created an attachment (id=19744)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19744&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42895
--- Comment #4 from carrot at google dot com 2010-01-29 19:42 ---
(In reply to comment #3)
> See arm.c:#define REG_ALLOC_ORDER. Comment before it says: " It is good to use
> ip since no saving is required (though calls clobber it) and it never contains
> function parameter
--- Comment #6 from carrot at google dot com 2010-01-29 22:47 ---
I tried to change the register order in REG_ALLOC_ORDER, moved ip and lr after
r4/r5/r6/r7, but I still got the same result.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42895
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48328
Summary: GCC failed to generate 16bit relative jump table
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48328
--- Comment #1 from Carrot 2011-03-30 07:25:31 UTC
---
Another possible enhancement is we can also use HImode jump table entries.
Similar to cases min<0, although tbh is not available in arm mode, we can use
separate instruction to load offset an
on: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: a
: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45039
Compile the following code with options -march=armv7-a -mthumb -Os
extern void foo(int*);
void tr(int array[], int n)
{
int i;
for (i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=45098
u dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45252
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45335
--- Comment #1 from carrot at google dot com 2010-08-20 03:13 ---
By simply define the following pattern
(define_insn "*thumb2_ldrd"
[(parallel [(set (match_operand:SI 0 "s_register_operand" "")
(mem:SI (match_operand:SI
--- Comment #4 from carrot at google dot com 2010-08-22 04:34 ---
Both have been fixed. But I don't have the permission to close PR43461.(In
reply to comment #3)
> Didn't Carrot's r163184 fix this PR and its dupe PR43461?
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44999
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45937
Summary: unnecessary push/pop to reserve stack memory
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45980
Summary: Use not in stead of add to generate new constant
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45980
--- Comment #1 from Carrot 2010-10-18 06:24:04 UTC
---
The replacement of constant loading with add operations is occurred at pass
postreload in function reload_cse_move2add. It is straight forward to extend
that to other ALU operations, such as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46092
Summary: Improve constant handling of thumb2 instructions
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46127
Summary: Use 16bit add instead of 32bit in thumb2
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46548
Summary: Build arm gcc failure after patch 165463
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46631
Summary: Change operands order so we can use 16bit and instead
of 32bit in thumb2
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46932
Summary: Inefficient code sequence to access local variable
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46975
Summary: Replace 32 bit instructions with 16 bit instructions
in thumb2
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
--- Comment #4 from carrot at google dot com 2010-04-29 02:23 ---
It is not only good to code size, but also benefit performance. For any path to
any successor block, the same number of taken branch executed, but less alu
instructions executed.
It may be difficult to calculate the
org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43988
gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44025
--- Comment #1 from carrot at google dot com 2010-05-07 13:19 ---
Created an attachment (id=20596)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20596&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44025
--- Comment #4 from carrot at google dot com 2010-05-11 03:21 ---
Fixed by http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00263.html.
--
carrot at google dot com changed:
What|Removed |Added
Summary: Use 'add r0, 1' to replace 'cmp r0, -1' in thumb2
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
--- Comment #1 from carrot at google dot com 2010-05-12 02:22 ---
It turns out that my original test case matches a conditional move pattern. It
shows another opportunity.
The following code demonstrates a simple compare and branch case
void foo1();
void bar5(int x)
{
if (x == -1
--- Comment #2 from carrot at google dot com 2010-05-25 02:28 ---
Fixed by http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00860.html.
Ramana, could you help to verify and close it?
thanks
Carrot
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44227
ields at the low end
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linu
dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44374
--- Comment #1 from carrot at google dot com 2010-06-02 08:20 ---
Created an attachment (id=20805)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20805&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44374
gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
--- Comment #10 from carrot at google dot com 2010-07-02 17:41 ---
The patch optimizes the prologue part only, the epilogue can also be enhanced.
Now compile the attached test case, I get
push{r0, r1, r2, lr}
add r0, sp, #4
bl bar
ldr r0
imization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44883
--- Comment #2 from carrot at google dot com 2010-07-09 00:04 ---
(In reply to comment #1)
> >So in function fwprop_addr before deciding propagate an expression should we
> also check if it is the only use of the corresponding def?
>
> It does somewhat. Though addres
--- Comment #4 from carrot at google dot com 2010-07-09 22:11 ---
Consider following case:
add r3, r1, r2
ldr r4, [r3]
Suppose there is no other usage of r3, propagate the first instruction into the
second and remove the first is the correct behavior and beneficial. This is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49573
Summary: wrong rtl pre transformation
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49573
Carrot changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49799
Summary: gcc arm generates illegal sbfx instruction
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49799
Carrot changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #4 from Carrot 201
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49799
--- Comment #6 from Carrot 2011-07-25 09:25:22 UTC
---
(In reply to comment #5)
> We should never generate a shift of -1. Instead the code that does that
> should
> return (clobber const_int 0).
I'm afraid this method may impact gcc too much.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49799
--- Comment #8 from Carrot 2011-07-26 02:51:39 UTC
---
(In reply to comment #7)
> No, you miss the point.
>
> Internally we must not generate (ashift (reg) (const_int)) where the const is
> negative.
>
> Note that your testcasegenerates a reg s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49799
Carrot changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
201 - 272 of 272 matches
Mail list logo
