* optimization, powerpc style
@ 2011-02-11 17:32 kevin diggs
2011-02-11 23:11 ` kevin diggs
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: kevin diggs @ 2011-02-11 17:32 UTC (permalink / raw)
To: gcc-help
[-- Attachment #1: Type: text/plain, Size: 3111 bytes --]
Hi,
While trying to figure out why the PowerMac mesh scsi driver will work
when compiled with 4.1.2 but not with 4.3.5 I noticed some strange
behavior with literal strings.
#include <stdio.h>
const char *getMsg(unsigned int u)
{
const char *p;
switch(u)
{
case 0:
p="This is message 0"; break;
case 1:
p="This is message 1"; break;
case 2:
p="This is message 2"; break;
case 3:
p="This is message 3"; break;
case 4:
p="This is message 4"; break;
case 5:
p="This is message 5"; break;
default:
p=NULL;
}
return p;
}
This function when compiled with 3.4.6 produces pretty good code.
4.3.5 produces lesser good code. Can someone suggest what I search the
bug database for to see if this has been reported and what the status
is? Is it PowerPC specific?
In both the 4.2.4 and 4.3.5 versions of mesh, the mesh_start() routine
has a lengthy list of register assignments near the start of the
routine:
.L241:
lis 9,.LANCHOR0@ha # tmp459,
lis 11,.LC47@ha # tmp461,
la 23,.LANCHOR0@l(9) # tmp460,, tmp459
lis 9,.LC48@ha # tmp463,
la 19,.LC47@l(11) # tmp462,, tmp461
la 18,.LC48@l(9) # tmp464,, tmp463
lis 11,.LC16@ha # tmp465,
lis 9,.LC50@ha # tmp467,
la 17,.LC16@l(11) # tmp466,, tmp465
la 22,.LC50@l(9) # tmp468,, tmp467
lis 11,.LC51@ha # tmp469,
lis 9,.LC57@ha # tmp471,
la 21,.LC51@l(11) # tmp470,, tmp469
la 20,.LC57@l(9) # tmp472,, tmp471
lis 11,.LC58@ha # tmp473,
lis 9,.LC59@ha # tmp475,
la 16,.LC58@l(11) # tmp474,, tmp473
la 15,.LC59@l(9) # tmp476,, tmp475
lis 11,.LC60@ha # tmp477,
lis 9,.LC53@ha # tmp480,
la 14,.LC60@l(11) # tmp478,, tmp477
la 24,.LC53@l(9) # tmp482,, tmp480
Later, when one of these is used you'll see:
mr 3,19 #, tmp462
mr 4,31 #, cmd
mr 6,28 #, id
bl printk #
for .LC47, which is "<4>mesh_start: %p ser=%lu tgt=%d cmd="
These all end up in:
.section .rodata.str1.4,"aMS",@progbits,1
and will have addresses close to each other, right? I don't understand
why they can't do something like:
lis 15,.LANCHOR0@ha
la 15,.LANCHOR0@l(15)
and then do something like:
la 3,<some offset>(15)
when each string is used. What am I missing?
The above register loads also result in:
stmw 14,8(1) #,
and
lmw 14,8(1) #,
for 4.3.5. A smaller set is saved in 4.1.2
stmw 25,20(1) #,
and
lmw 25,20(1) #,
Won't this lead to unneeded memory traffic and/or cache churning?
kevin
P.S.: For all those who send email from their Blackberry's and iphones:
Sent from my 33 MHz 386 using Firefox 2!
[-- Attachment #2: gcctest1-3.4.6.s --]
[-- Type: application/octet-stream, Size: 2978 bytes --]
.file "gcctest1.c"
# rs6000/powerpc options: -mcpu=750 -msdata=data -G 8
# GNU C version 3.4.6 (powerpc-unknown-linux-gnu)
# compiled by GNU C version 3.4.6.
# GGC heuristics: --param ggc-min-expand=59 --param ggc-min-heapsize=55787
# options passed: -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix
# -Dlinux -D__linux -Asystem=linux -Asystem=unix -Asystem=posix -mcpu=750
# -mmultiple -auxbase-strip -O2 -fverbose-asm -ogcctest1-3.4.6.s
# options enabled: -feliminate-unused-debug-types -fdefer-pop
# -fomit-frame-pointer -foptimize-sibling-calls -funit-at-a-time
# -fcse-follow-jumps -fcse-skip-blocks -fexpensive-optimizations
# -fthread-jumps -fstrength-reduce -fpeephole -fforce-mem -ffunction-cse
# -fkeep-static-consts -fcaller-saves -freg-struct-return -fgcse -fgcse-lm
# -fgcse-sm -fgcse-las -floop-optimize -fcrossjumping -fif-conversion
# -fif-conversion2 -frerun-cse-after-loop -frerun-loop-opt
# -fdelete-null-pointer-checks -fschedule-insns -fschedule-insns2
# -fsched-interblock -fsched-spec -fsched-stalled-insns
# -fsched-stalled-insns-dep -fbranch-count-reg -freorder-blocks
# -freorder-functions -fcprop-registers -fcommon -fverbose-asm -fregmove
# -foptimize-register-move -fargument-alias -fstrict-aliasing
# -fmerge-constants -fzero-initialized-in-bss -fident -fpeephole2
# -fguess-branch-probability -fmath-errno -ftrapping-math -mpowerpc
# -mpowerpc-gfxopt -mnew-mnemonics -mmultiple -msched-prolog
# -msched-epilog -maix-struct-return -mno-svr4-struct-return -mcpu=750
# -mcall-sysv -msdata=data
.section .rodata.str1.4,"aMS",@progbits,1
.align 2
.LC5:
.string "This is message 5"
.align 2
.LC0:
.string "This is message 0"
.align 2
.LC1:
.string "This is message 1"
.align 2
.LC2:
.string "This is message 2"
.align 2
.LC3:
.string "This is message 3"
.align 2
.LC4:
.string "This is message 4"
.section ".text"
.align 2
.globl getMsg
.type getMsg, @function
getMsg:
cmplwi 7,3,5 #, tmp127, u
li 9,0 # p,
bgt- 7,.L2 #
lis 9,.L10@ha # tmp129,
slwi 0,3,2 #, tmp131, u
la 9,.L10@l(9) # tmp128,, tmp129
lwzx 11,9,0 #, tmp133
add 11,11,9 #, tmp133, tmp128
mtctr 11 # tmp136,
bctr
.section .rodata
.align 2
.align 2
.L10:
.long .L3-.L10
.long .L4-.L10
.long .L5-.L10
.long .L6-.L10
.long .L7-.L10
.long .L8-.L10
.section ".text"
.L8:
lis 9,.LC5@ha # tmp126,
la 9,.LC5@l(9) # p,, tmp126
.L2:
mr 3,9 # <result>, p
blr #
.L3:
lis 9,.LC0@ha # tmp121,
la 9,.LC0@l(9) # p,, tmp121
mr 3,9 # <result>, p
blr #
.L4:
lis 9,.LC1@ha # tmp122,
la 9,.LC1@l(9) # p,, tmp122
mr 3,9 # <result>, p
blr #
.L5:
lis 9,.LC2@ha # tmp123,
la 9,.LC2@l(9) # p,, tmp123
mr 3,9 # <result>, p
blr #
.L6:
lis 9,.LC3@ha # tmp124,
la 9,.LC3@l(9) # p,, tmp124
mr 3,9 # <result>, p
blr #
.L7:
lis 9,.LC4@ha # tmp125,
la 9,.LC4@l(9) # p,, tmp125
mr 3,9 # <result>, p
blr #
.size getMsg, .-getMsg
.section .note.GNU-stack,"",@progbits
.ident "GCC: (GNU) 3.4.6"
[-- Attachment #3: gcctest1-4.3.5.s --]
[-- Type: application/octet-stream, Size: 3573 bytes --]
.file "gcctest1.c"
# rs6000/powerpc options: -mcpu=750 -msdata=data -G 8
# GNU C (GCC) version 4.3.5 (powerpc-unknown-linux-gnu)
# compiled by GNU C version 4.3.5, GMP version 4.3.2, MPFR version 2.4.2.
# GGC heuristics: --param ggc-min-expand=59 --param ggc-min-heapsize=55787
# options passed: -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix
# -Dlinux -D__linux -Asystem=linux -Asystem=unix -Asystem=posix gcctest1.c
# -mcpu=750 -mmultiple -auxbase-strip gcctest1-4.3.5.s -O2 -fverbose-asm
# -ogcctest1-4.3.5.s
# options enabled: -falign-loops -fargument-alias -fauto-inc-dec
# -fbranch-count-reg -fcaller-saves -fcommon -fcprop-registers
# -fcrossjumping -fcse-follow-jumps -fdefer-pop
# -fdelete-null-pointer-checks -fearly-inlining
# -feliminate-unused-debug-types -fexpensive-optimizations
# -fforward-propagate -ffunction-cse -fgcse -fgcse-lm
# -fguess-branch-probability -fident -fif-conversion -fif-conversion2
# -finline-functions-called-once -finline-small-functions -fipa-pure-const
# -fipa-reference -fivopts -fkeep-static-consts -fleading-underscore
# -fmath-errno -fmerge-constants -fmerge-debug-strings
# -fmove-loop-invariants -fomit-frame-pointer -foptimize-register-move
# -foptimize-sibling-calls -fpeephole -fpeephole2 -freg-struct-return
# -fregmove -freorder-blocks -freorder-functions -frerun-cse-after-loop
# -fsched-interblock -fsched-spec -fsched-stalled-insns-dep
# -fschedule-insns -fschedule-insns2 -fsection-anchors -fsigned-zeros
# -fsplit-ivs-in-unroller -fsplit-wide-types -fstrict-aliasing
# -fstrict-overflow -fthread-jumps -ftoplevel-reorder -ftrapping-math
# -ftree-ccp -ftree-ch -ftree-copy-prop -ftree-copyrename -ftree-cselim
# -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-fre -ftree-loop-im
# -ftree-loop-ivcanon -ftree-loop-optimize -ftree-parallelize-loops=
# -ftree-pre -ftree-reassoc -ftree-salias -ftree-scev-cprop -ftree-sink
# -ftree-sra -ftree-store-ccp -ftree-ter -ftree-vect-loop-version
# -ftree-vrp -funit-at-a-time -fverbose-asm -fzero-initialized-in-bss -m32
# -maix-struct-return -mbig -mbig-endian -mbss-plt -mfused-madd -mglibc
# -mhard-float -mmultiple -mnew-mnemonics -mno-fp-in-toc -mpowerpc
# -mpowerpc-gfxopt -msched-prolog -mupdate
# Compiler executable checksum: ee44f4fe3383fc2df57269e53aea3cc9
.section ".text"
.align 2
.globl getMsg
.type getMsg, @function
getMsg:
cmplwi 7,3,5 #, tmp122, u
mr 0,3 # u, u
li 3,0 # p,
bgtlr- 7
lis 9,.L9@ha # tmp124,
slwi 0,0,2 # tmp125, u,
la 9,.L9@l(9) # tmp123,, tmp124
lwzx 11,9,0 #, tmp127
add 11,11,9 #, tmp127, tmp123
mtctr 11 # tmp130,
bctr
.section .rodata
.align 2
.align 2
.L9:
.long .L3-.L9
.long .L4-.L9
.long .L5-.L9
.long .L6-.L9
.long .L7-.L9
.long .L8-.L9
.section ".text"
.L8:
lis 9,.LC5@ha # tmp136,
la 3,.LC5@l(9) # p,, tmp136
blr
.L3:
lis 9,.LC1@ha # tmp132,
la 3,.LC1@l(9) # p,, tmp132
blr
.L4:
lis 9,.LC0@ha # tmp131,
la 3,.LC0@l(9) # p,, tmp131
blr
.L5:
lis 9,.LC2@ha # tmp133,
la 3,.LC2@l(9) # p,, tmp133
blr
.L6:
lis 9,.LC3@ha # tmp134,
la 3,.LC3@l(9) # p,, tmp134
blr
.L7:
lis 9,.LC4@ha # tmp135,
la 3,.LC4@l(9) # p,, tmp135
blr
.size getMsg, .-getMsg
.section .rodata.str1.4,"aMS",@progbits,1
.align 2
.LC0:
.string "This is message 1"
.zero 2
.LC1:
.string "This is message 0"
.zero 2
.LC2:
.string "This is message 2"
.zero 2
.LC3:
.string "This is message 3"
.zero 2
.LC4:
.string "This is message 4"
.zero 2
.LC5:
.string "This is message 5"
.ident "GCC: (GNU) 4.3.5"
.section .note.GNU-stack,"",@progbits
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: optimization, powerpc style
2011-02-11 17:32 optimization, powerpc style kevin diggs
@ 2011-02-11 23:11 ` kevin diggs
2011-02-12 6:21 ` kevin diggs
2011-02-15 21:38 ` kevin diggs
2011-02-25 8:05 ` kevin diggs
2 siblings, 1 reply; 6+ messages in thread
From: kevin diggs @ 2011-02-11 23:11 UTC (permalink / raw)
To: gcc-help
Hi,
Please ignore the first half of the original post. I used the size
command to make a snap judgment on the code without looking very hard
at the assembly I posted. After actually looking at the code I
realized that I created the .o files from the wrong .s files. In this
case the 4.3.5 compiler DOES do a better job.
I still think the questions about the mesh compiles are valid if
anyone has any thoughts.
Thanks (and sorry)!
kevin
On Fri, Feb 11, 2011 at 11:15 AM, kevin diggs <diggskevin38@gmail.com> wrote:
> Hi,
>
> While trying to figure out why the PowerMac mesh scsi driver will work
> when compiled with 4.1.2 but not with 4.3.5 I noticed some strange
> behavior with literal strings.
>
> #include <stdio.h>
>
> const char *getMsg(unsigned int u)
> {
> const char *p;
>
> switch(u)
> {
> case 0:
> p="This is message 0"; break;
> case 1:
> p="This is message 1"; break;
> case 2:
> p="This is message 2"; break;
> case 3:
> p="This is message 3"; break;
> case 4:
> p="This is message 4"; break;
> case 5:
> p="This is message 5"; break;
> default:
> p=NULL;
> }
>
> return p;
> }
>
> This function when compiled with 3.4.6 produces pretty good code.
> 4.3.5 produces lesser good code. Can someone suggest what I search the
> bug database for to see if this has been reported and what the status
> is? Is it PowerPC specific?
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: optimization, powerpc style
2011-02-11 23:11 ` kevin diggs
@ 2011-02-12 6:21 ` kevin diggs
0 siblings, 0 replies; 6+ messages in thread
From: kevin diggs @ 2011-02-12 6:21 UTC (permalink / raw)
To: gcc-help
Hi,
Something like this:
@@ -46,6 +46,8 @@
mr 0,3 # u, u
li 3,0 # p,
bgtlr- 7
+ lis 8,.LCANCHOR@ha
+ la 8,.LCANCHOR@l(8)
lis 9,.L9@ha # tmp124,
slwi 0,0,2 # tmp125, u,
la 9,.L9@l(9) # tmp123,, tmp124
@@ -65,28 +67,22 @@
.long .L8-.L9
.section ".text"
.L8:
- lis 9,.LC5@ha # tmp136,
- la 3,.LC5@l(9) # p,, tmp136
+ la 3,.LC5-.LCANCHOR(8)
blr
.L3:
- lis 9,.LC1@ha # tmp132,
- la 3,.LC1@l(9) # p,, tmp132
+ la 3,.LC1-.LCANCHOR(8)
blr
.L4:
- lis 9,.LC0@ha # tmp131,
- la 3,.LC0@l(9) # p,, tmp131
+ la 3,.LC0-.LCANCHOR(8)
blr
.L5:
- lis 9,.LC2@ha # tmp133,
- la 3,.LC2@l(9) # p,, tmp133
+ la 3,.LC2-.LCANCHOR(8)
blr
.L6:
- lis 9,.LC3@ha # tmp134,
- la 3,.LC3@l(9) # p,, tmp134
+ la 3,.LC3-.LCANCHOR(8)
blr
.L7:
- lis 9,.LC4@ha # tmp135,
- la 3,.LC4@l(9) # p,, tmp135
+ la 3,.LC4-.LCANCHOR(8)
blr
.size getMsg, .-getMsg
.align 2
@@ -165,6 +161,7 @@
.LC2:
.string "This is message 2"
.zero 2
+.LCANCHOR:
.LC3:
.string "This is message 3"
.zero 2
kevin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: optimization, powerpc style
2011-02-11 17:32 optimization, powerpc style kevin diggs
2011-02-11 23:11 ` kevin diggs
@ 2011-02-15 21:38 ` kevin diggs
2011-02-25 8:05 ` kevin diggs
2 siblings, 0 replies; 6+ messages in thread
From: kevin diggs @ 2011-02-15 21:38 UTC (permalink / raw)
To: gcc-help
Hi,
On Fri, Feb 11, 2011 at 11:15 AM, kevin diggs <diggskevin38@gmail.com> wrote:
>
> In both the 4.2.4 and 4.3.5 versions of mesh, the mesh_start() routine
> has a lengthy list of register assignments near the start of the
> routine:
>
> .L241:
> lis 9,.LANCHOR0@ha # tmp459,
> lis 11,.LC47@ha # tmp461,
> la 23,.LANCHOR0@l(9) # tmp460,, tmp459
> lis 9,.LC48@ha # tmp463,
> la 19,.LC47@l(11) # tmp462,, tmp461
> la 18,.LC48@l(9) # tmp464,, tmp463
> lis 11,.LC16@ha # tmp465,
> lis 9,.LC50@ha # tmp467,
> la 17,.LC16@l(11) # tmp466,, tmp465
> la 22,.LC50@l(9) # tmp468,, tmp467
> lis 11,.LC51@ha # tmp469,
> lis 9,.LC57@ha # tmp471,
> la 21,.LC51@l(11) # tmp470,, tmp469
> la 20,.LC57@l(9) # tmp472,, tmp471
> lis 11,.LC58@ha # tmp473,
> lis 9,.LC59@ha # tmp475,
> la 16,.LC58@l(11) # tmp474,, tmp473
> la 15,.LC59@l(9) # tmp476,, tmp475
> lis 11,.LC60@ha # tmp477,
> lis 9,.LC53@ha # tmp480,
> la 14,.LC60@l(11) # tmp478,, tmp477
> la 24,.LC53@l(9) # tmp482,, tmp480
>
> Later, when one of these is used you'll see:
>
> mr 3,19 #, tmp462
> mr 4,31 #, cmd
> mr 6,28 #, id
> bl printk #
>
> for .LC47, which is "<4>mesh_start: %p ser=%lu tgt=%d cmd="
>
> These all end up in:
>
> .section .rodata.str1.4,"aMS",@progbits,1
>
> and will have addresses close to each other, right? I don't understand
> why they can't do something like:
>
> lis 15,.LANCHOR0@ha
> la 15,.LANCHOR0@l(15)
>
> and then do something like:
>
> la 3,<some offset>(15)
>
> when each string is used. What am I missing?
>
> The above register loads also result in:
>
> stmw 14,8(1) #,
> and
> lmw 14,8(1) #,
>
> for 4.3.5. A smaller set is saved in 4.1.2
>
> stmw 25,20(1) #,
> and
> lmw 25,20(1) #,
>
> Won't this lead to unneeded memory traffic and/or cache churning?
>
> kevin
>
> P.S.: For all those who send email from their Blackberry's and iphones:
>
> Sent from my 33 MHz 386 using Firefox 2!
>
Is this something I could have caused by screwing up the build of the
4.3.5 compiler?
Thanks!
kevin
P.S.: NOT sent from my 33 MHz 386 (currently off - but I may play
Atarisoft Pacman later today) nor Firefox2
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: optimization, powerpc style
2011-02-11 17:32 optimization, powerpc style kevin diggs
2011-02-11 23:11 ` kevin diggs
2011-02-15 21:38 ` kevin diggs
@ 2011-02-25 8:05 ` kevin diggs
2 siblings, 0 replies; 6+ messages in thread
From: kevin diggs @ 2011-02-25 8:05 UTC (permalink / raw)
To: gcc-help
On Fri, Feb 11, 2011 at 11:15 AM, kevin diggs <diggskevin38@gmail.com> wrote:
>
> In both the 4.2.4 and 4.3.5 compiled versions of mesh, the mesh_start() routine
> has a lengthy list of register assignments near the start of the
> routine:
>
> .L241:
> lis 9,.LANCHOR0@ha # tmp459,
> lis 11,.LC47@ha # tmp461,
> la 23,.LANCHOR0@l(9) # tmp460,, tmp459
> lis 9,.LC48@ha # tmp463,
> la 19,.LC47@l(11) # tmp462,, tmp461
> la 18,.LC48@l(9) # tmp464,, tmp463
> lis 11,.LC16@ha # tmp465,
> lis 9,.LC50@ha # tmp467,
> la 17,.LC16@l(11) # tmp466,, tmp465
> la 22,.LC50@l(9) # tmp468,, tmp467
> lis 11,.LC51@ha # tmp469,
> lis 9,.LC57@ha # tmp471,
> la 21,.LC51@l(11) # tmp470,, tmp469
> la 20,.LC57@l(9) # tmp472,, tmp471
> lis 11,.LC58@ha # tmp473,
> lis 9,.LC59@ha # tmp475,
> la 16,.LC58@l(11) # tmp474,, tmp473
> la 15,.LC59@l(9) # tmp476,, tmp475
> lis 11,.LC60@ha # tmp477,
> lis 9,.LC53@ha # tmp480,
> la 14,.LC60@l(11) # tmp478,, tmp477
> la 24,.LC53@l(9) # tmp482,, tmp480
>
> Later, when one of these is used you'll see:
>
> mr 3,19 #, tmp462
> mr 4,31 #, cmd
> mr 6,28 #, id
> bl printk #
>
> for .LC47, which is "<4>mesh_start: %p ser=%lu tgt=%d cmd="
>
> These all end up in:
>
> .section .rodata.str1.4,"aMS",@progbits,1
>
> and will have addresses close to each other, right? I don't understand
> why they can't do something like:
>
> lis 15,.LANCHOR0@ha
> la 15,.LANCHOR0@l(15)
>
> and then do something like:
>
> la 3,<some offset>(15)
>
> when each string is used. What am I missing?
>
> The above register loads also result in:
>
> stmw 14,8(1) #,
> and
> lmw 14,8(1) #,
>
> for 4.3.5. A smaller set is saved in 4.1.2
>
> stmw 25,20(1) #,
> and
> lmw 25,20(1) #,
>
> Won't this lead to unneeded memory traffic and/or cache churning?
>
> kevin
>
Hi,
Before I work on this, has it already been fixed in a newer release?
Thanks!
kevin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: optimization, powerpc style
@ 2011-02-12 1:51 Bill McEnaney
0 siblings, 0 replies; 6+ messages in thread
From: Bill McEnaney @ 2011-02-12 1:51 UTC (permalink / raw)
To: kevin diggs, gcc-help
I don't know the answer to Kevin's question, but why not replace the switch statement with an
array full of messages? Then use the message number as a subscript to choose the correct
message. He could keep the messages in a file that begins with the message count.
Kevin Diggs writes:
> Hi,
>
> Please ignore the first half of the original post. I used the size
> command to make a snap judgment on the code without looking very hard
> at the assembly I posted. After actually looking at the code I
> realized that I created the .o files from the wrong .s files. In this
> case the 4.3.5 compiler DOES do a better job.
>
> I still think the questions about the mesh compiles are valid if
> anyone has any thoughts.
>
> Thanks (and sorry)!
>
> kevin
>
> On Fri, Feb 11, 2011 at 11:15 AM, kevin diggs <diggskevin38@gmail.com> wrote:
> > Hi,
> >
> > While trying to figure out why the PowerMac mesh scsi driver will work
> > when compiled with 4.1.2 but not with 4.3.5 I noticed some strange
> > behavior with literal strings.
> >
> > #include <stdio.h>
> >
> > const char *getMsg(unsigned int u)
> > {
> > const char *p;
> >
> > switch(u)
> > {
> > case 0:
> > p="This is message 0"; break;
> > case 1:
> > p="This is message 1"; break;
> > case 2:
> > p="This is message 2"; break;
> > case 3:
> > p="This is message 3"; break;
> > case 4:
> > p="This is message 4"; break;
> > case 5:
> > p="This is message 5"; break;
> > default:
> > p=NULL;
> > }
> >
> > return p;
> > }
> >
> > This function when compiled with 3.4.6 produces pretty good code.
> > 4.3.5 produces lesser good code. Can someone suggest what I search the
> > bug database for to see if this has been reported and what the status
> > is? Is it PowerPC specific?
> >
>
>
________________________________________________________________
Please visit a saintly hero:
http://www.jakemoore.org
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-02-25 1:56 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-02-11 17:32 optimization, powerpc style kevin diggs
2011-02-11 23:11 ` kevin diggs
2011-02-12 6:21 ` kevin diggs
2011-02-15 21:38 ` kevin diggs
2011-02-25 8:05 ` kevin diggs
2011-02-12 1:51 Bill McEnaney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).