[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
--- Comment #7 from pranav dot bhandarkar at gmail dot com 2007-10-17
10:49 ---
Created an attachment (id=14362)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14362action=view)
Reduced Testcase. Small Code, huge datastructure.
In the attached testcase due to an ivopts modification, while
rewriting the uses (rewrite_uses) the compiler crashes in tree-ssa-operands.c
because the memory required for the virtual operands of the modified stmt is
much greater than the thresholds controlled by OP_SIZE_{1,2,3} in
tree-ssa-operands.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
--- Comment #8 from pranav dot bhandarkar at gmail dot com 2007-10-17 10:50 --- Adding Andrew here. -- pranav dot bhandarkar at gmail dot com changed: What|Removed |Added CC||amacleod at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
[Bug middle-end/33315] New: If condition not getting eliminated
if ( x == 8 ) statement1 if ( x != 8 ) statement1 if ( x == 9 ) statement2 if ( x != 9 ) statement2 should be replaced by statement1 statement2 However this doesnt happen and compare and jumps do get generated. -- Summary: If condition not getting eliminated Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pranav dot bhandarkar at gmail dot com GCC target triplet: arm-none-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33315
[Bug middle-end/33315] If condition not getting eliminated
--- Comment #1 from pranav dot bhandarkar at gmail dot com 2007-09-05 19:03 --- Created an attachment (id=14158) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14158action=view) Sample Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33315
[Bug rtl-optimization/32283] Missed induction variable optimization
--- Comment #8 from pranav dot bhandarkar at gmail dot com 2007-08-24
13:28 ---
Created an attachment (id=14102)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14102action=view)
Another testcase displaying the said behaviour
IMHO, the code generated for the following can benefit from Strength reduction.
It will be possible to generate post_inc due to strength reduction.
for (dp = i = 0; i c; i++) {
dp += a[i] * b[i];
}
The RTL code generated for the loop is of the form ( numbers represent pseudo
reg numbers)
137 and 136 hold the base addresses of the two arrays before entry into the
loop.
132 = 0 ; #i,
133 = 132 ; #dp
Label:
139 = *(137 + 132)
140 = *(136 + 132)
141 = 140 * 139
133 += 141 ;#dp
132 += 2
conditional_jump back to Label.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
[Bug c++/32716] New: Wrong code generation. Inlining problem.
Generating wrong code for the following code snippet (test.C)
using namespace std;
#include iostream
class A { public:int a;};
class B: public virtual A { public: A::a;};
class C : public virtual A { public:A::a;};
class D : public C, public B {};
void h ( D x )
{
x.a++;
}
int main ()
{
int result ;
D d;
d.a = 0;
h (d);
result = !(d.a==1);
result ? coutFAILED: cout SUCCESS;
return 0;
}
$arm-none-eabi-g++ -O3 test.C
$ arm-none-eabi-run a.out
FAILED
$arm-none-eabi-g++ -O3 test.C -fno-inline-functions
$ arm-none-eabi-run a.out
SUCCESS
$arm-none-eabi-g++ --version
arm-none-eabi-g++ (GCC) 4.3.0 20070703 (experimental)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--
Summary: Wrong code generation. Inlining problem.
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pranav dot bhandarkar at gmail dot com
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32716
[Bug c++/32716] Wrong code generation. Inlining problem.
--- Comment #1 from pranav dot bhandarkar at gmail dot com 2007-07-10 10:02 --- Created an attachment (id=13876) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13876action=view) Dump of the early inline pass, that highlights the problem with the inliner h() gets inlined into main but the result of the increment in h() is not used in main after inlining causing 0 to be assigned to result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32716
[Bug rtl-optimization/32283] Missed induction variable optimization
--- Comment #7 from pranav dot bhandarkar at gmail dot com 2007-06-14 20:50 --- I guess strength reduction should then be implemented at the RTL level ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
[Bug rtl-optimization/32283] Missed induction variable optimization
--- Comment #5 from pranav dot bhandarkar at gmail dot com 2007-06-13 12:36 --- Which RTL pass should take care of such induction variable optimization in 4.3 ? For e.g In 4.1, It was old-loop that was doing it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
[Bug tree-optimization/32306] New: Bad Code generation ( Tree optimization )
For the following Code Snippet
void bar ()
{
b1 = foo(1);
b2 = foo(1);
b3 = foo(1);
b4 = foo(1);
b5 = foo(1);
b6 = foo(1);
b7 = foo(1);
b8 = foo(1);
b9 = foo(1);
b10 = foo(1);
b11 = foo(1);
b12 = foo(1);
array[0] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[1] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[2] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[3] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[4] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[5] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[6] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[7] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[8] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[9] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[10] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
return;
}
Where b ( from b1 to b12) are all declared static short b1, static short b2
etc.
and array is static short array[11].
This should generate code such as
if (b1 == 0) goto L1 else goto L2
L2:
if (b2 == 0) goto L1 else goto L3
L3:
if (b3 == 0) goto L1 else goto L4
L4:
if (b4 == 0) goto L1 else goto L5
L5:
if (b5 == 0) goto L1 else goto L6
L6:
if (b6 == 0) goto L1 else goto L7
L7:
if (b7 == 0) goto L1 else goto L8
L8:
if (b8 == 0) goto L1 else goto L9
L9:
if (b9 == 0) goto L1 else goto L10
L10:
if (b10 == 0) goto L1 else goto L11
L11:
if (b11 == 0) goto L1 else goto L12
L12:
if (b12 == 0) goto L1 else goto L13
L13:
array[i]=1 (for i from 0 to 10)
return
L1:
array[i]=0 (for i from 0 to 10)
return
This is exactly what 4.1 generates but 4.3 fails to combine the if sequences.
Version Details:
GNU C version 4.3.0 20070316 (experimental) (arm-none-eabi)
compiled by GNU C version 3.4.6 (Ubuntu 3.4.6-1ubuntu2).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
--
Summary: Bad Code generation ( Tree optimization )
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pranav dot bhandarkar at gmail dot com
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
[Bug tree-optimization/32306] Bad Code generation ( Tree optimization )
--- Comment #1 from pranav dot bhandarkar at gmail dot com 2007-06-12 14:48 --- Created an attachment (id=13686) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13686action=view) Tes -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
[Bug tree-optimization/32306] Bad Code generation ( Tree optimization )
--- Comment #2 from pranav dot bhandarkar at gmail dot com 2007-06-12 14:50 --- Created an attachment (id=13687) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13687action=view) Code Generated by 4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
[Bug tree-optimization/32306] Bad Code generation ( Tree optimization )
--- Comment #3 from pranav dot bhandarkar at gmail dot com 2007-06-12 14:50 --- Created an attachment (id=13688) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13688action=view) Code Generated by 4.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
[Bug tree-optimization/32306] [4.2/4.3 Regression] Bad Code generation ( Tree optimization )
--- Comment #5 from pranav dot bhandarkar at gmail dot com 2007-06-12 21:10 --- Created an attachment (id=13694) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13694action=view) A smaller Testcase that displays the said behaviour Reduced the testcase. Reducing to less than b1 thru b6 results in the compiler being able to combine the if conditions at the tree level. Therefore couldnt reduce it to less than b6. array elements written have been reduced to 4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
[Bug tree-optimization/32306] [4.2/4.3 Regression] Bad Code generation ( Tree optimization )
--- Comment #6 from pranav dot bhandarkar at gmail dot com 2007-06-12 21:14 --- dom, in 4.1 is able to combine the if conditions unlike 4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
[Bug rtl-optimization/32283] New: Missed induction variable optimization
Consider the following code snippet
static volatile short a[(2048)];
short foo (int len, int v)
{
int i;
for (i = 0; i len; i++) {
a[i] = v;
}
return a[0];
}
This should generate a post_inc for accessing elements of a. The problem seems
to be in the loop optimizer that fails to identify 'i' as an induction
variable. For e.g the dump from 141r.loop2_invariant shows
(insn 16 15 75 4 (set (reg/v:SI 103 [ i ])
(const_int 0 [0x0])) 161 {*arm_movsi_insn} (nil))
(insn 75 16 17 4 (set (reg/f:SI 118)
(symbol_ref:SI (^a) [flags 0x2] var_decl 0xb7dc1000 a)) -1 (nil))
(code_label 17 75 18 5 4 [0 uses])
(note 18 17 21 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(insn 21 18 23 5 (set (reg:SI 110)
(ashift:SI (reg/v:SI 103 [ i ])
(const_int 1 [0x1]))) 115 {*arm_shiftsi3} (nil))
(insn 23 21 25 5 (set (mem/s/v:HI (plus:SI (reg:SI 110)
(reg/f:SI 118)) [3 a S2 A16])
(subreg/s/u:HI (reg:SI 102 [ pretmp.21 ]) 0)) 171 {*movhi_insn_arch4}
(nil))
(insn 25 23 26 5 (set (reg/v:SI 103 [ i ])
(plus:SI (reg/v:SI 103 [ i ])
(const_int 1 [0x1]))) 4 {*arm_addsi3} (nil))
(insn 26 25 27 5 (set (reg:CC 24 cc)
(compare:CC (reg/v:SI 106 [ len ])
(reg/v:SI 103 [ i ]))) 214 {*arm_cmpsi_insn} (nil))
(jump_insn 27 26 82 5 (set (pc)
(if_then_else (gt (reg:CC 24 cc)
(const_int 0 [0x0]))
(label_ref:SI 82)
(pc))) 224 {*arm_cond_branch} (expr_list:REG_BR_PROB (const_int
9900 [0x26ac])
(nil)))
Here reg 103 i.e 'i' is incremented by 1 always and therefore 110 always
increases by 2 which means that in each iteration the address in INSN 23 is 2
more than what it was in the previous iteration. If the access is converted
into something like
*118 = v
118 += 2,
then the auto-inc-dec pass will be able to convert this into a post_inc
Version Details:
GNU C version 4.3.0 20070316 (experimental) (arm-none-eabi)
compiled by GNU C version 3.4.6 (Ubuntu 3.4.6-1ubuntu2).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
--
Summary: Missed induction variable optimization
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pranav dot bhandarkar at gmail dot com
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
[Bug rtl-optimization/32283] Missed induction variable optimization
--- Comment #1 from pranav dot bhandarkar at gmail dot com 2007-06-11 13:45 --- Created an attachment (id=13676) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13676action=view) Testcase displaying the said behaviour Added testcase that exposes the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
[Bug rtl-optimization/32283] Missed induction variable optimization
--- Comment #3 from pranav dot bhandarkar at gmail dot com 2007-06-11 14:33 --- (In reply to comment #2) What if you remove the pointless 'volatile' from a? No, removing the 'volatile' doesnt help either. The 'volatile' was because this is part of a bigger test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
[Bug middle-end/31241] New: Post Increment opportunity missed
A simple code that adds a 'value' too all the elements of an array should
generate post increments while loading/storing values from/into the array. The
code looks something like this
for (i = 0; i 10; i++) {
*(intArray++) |= value;
}
However a post increment is not generated at O3 ( that causes the
tree-optimizer to unroll the loop)
Here is the information of the toolchain and the code produced.
$arm-none-eabi-gcc -v -O3 -S enhance.c --save-temps -o-
Using built-in specs.
Target: arm-none-eabi
Configured with:
/mnt/tools/fsf/build/combined-arm-none-eabi-gcc-4.2-branch-2007-03-16/configure
--target=arm-none-eabi
--prefix=/mnt/tools/fsf/install/arm-none-eabi-gcc-4.2-branch-2007-03-16
--enable-languages=c,c++ --disable-nls --with-newlib --disable-gdbtk
--disable-libssp
Thread model: single
gcc version 4.2.0 20070315 (prerelease)
/mnt/tools/fsf/install/arm-none-eabi-gcc-4.2-branch-2007-03-16/libexec/gcc/arm-none-eabi/4.2.0/cc1
-E -quiet -v -D__USES_INITFINI__ enhance.c -O3 -fpch-preprocess -o enhance.i
ignoring nonexistent directory
/mnt/tools/fsf/install/arm-none-eabi-gcc-4.2-branch-2007-03-16/lib/gcc/arm-none-eabi/4.2.0/../../../../arm-none-eabi/sys-include
ignoring nonexistent directory
/mnt/tools/fsf/install/arm-none-eabi-gcc-4.2-branch-2007-03-16/lib/gcc/arm-none-eabi/4.2.0/../../../../arm-none-eabi/include#include
... search starts here:
#include ... search starts here:
/mnt/tools/fsf/install/arm-none-eabi-gcc-4.2-branch-2007-03-16/lib/gcc/arm-none-eabi/4.2.0/include
End of search list.
/mnt/tools/fsf/install/arm-none-eabi-gcc-4.2-branch-2007-03-16/libexec/gcc/arm-none-eabi/4.2.0/cc1
-fpreprocessed enhance.i -quiet -dumpbase enhance.c -auxbase-strip - -O3
-version -o-
GNU C version 4.2.0 20070315 (prerelease) (arm-none-eabi)
compiled by GNU C version 4.0.3 (Ubuntu 4.0.3-1ubuntu5).
GGC heuristics: --param ggc-min-expand=97 --param ggc-min-heapsize=127206
Compiler executable checksum: 31464fade10aeea055a352aa873c9729
.file enhance.c
.text
.align 2
.global ShouldUsePostModify
.type ShouldUsePostModify, %function
ShouldUsePostModify:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldr ip, [r0, #0]
mov r3, r0
orr ip, ip, r1
str ip, [r3], #4
ldr r2, [r0, #4]
orr r2, r2, r1
str r2, [r0, #4]
ldr r0, [r3, #4]
orr r0, r0, r1
str r0, [r3, #4]
add r3, r3, #4
ldr r2, [r3, #4]
orr r2, r2, r1
str r2, [r3, #4]
add r3, r3, #4
ldr r2, [r3, #4]
orr r2, r2, r1
str r2, [r3, #4]
add r3, r3, #4
ldr r2, [r3, #4]
orr r2, r2, r1
str r2, [r3, #4]
add r3, r3, #4
ldr r2, [r3, #4]
orr r2, r2, r1
str r2, [r3, #4]
add r3, r3, #4
ldr r2, [r3, #4]
orr r2, r2, r1
str r2, [r3, #4]
add r3, r3, #4
ldr r2, [r3, #4]
orr r2, r2, r1
str r2, [r3, #4]
add r3, r3, #4
ldr r2, [r3, #4]
orr r2, r2, r1
@ lr needed for prologue
str r2, [r3, #4]
bx lr
.size ShouldUsePostModify, .-ShouldUsePostModify
.ident GCC: (GNU) 4.2.0 20070315 (prerelease)
However this problem vanishes when I use -fno-tree-lrs, this is becuase, then
each copy of intArray created by the unroller gets combined and the load/ store
can be combined with the increment of intArray. However, I dont think that this
( the use of -fno-tree-lrs) is the way to go.
--
Summary: Post Increment opportunity missed
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pranav dot bhandarkar at gmail dot com
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31241
[Bug middle-end/31241] Post Increment opportunity missed
--- Comment #1 from pranav dot bhandarkar at gmail dot com 2007-03-17 14:13 --- Created an attachment (id=13218) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13218action=view) Source that exposes the mentioned deficiency in the compiler -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31241
