Re: -fno-unswitch-loops option have no effect?
Hi, Hundreds and hundreds of people read this list, so every low-detail I think there may be a bug message you send wastes hours of other people's time. Ok, Ok, but if someone will reproduce the same problem on his system I can fill bugreport, otherwise I will only waste my time, hours of my time, to start detailed bugreport. Maybe this is only fault of my GCC's build? If it *is* a bug, on the bug tracker, it will be picked up by people interested in that specific area It may takes months before someone will look at the bugreport. If it's really a bug IMHO it's a bit critical bug. though you don't seem to do much in-depth research, nor do you supply any detail of what you did and what you expected. There is no need for much detail, just compile any bigger sourcecode with -O3 -fno-.. and after that with -O2 When the object files are not identical, something is wrong and I can start a bug report. Regards
Re: -fno-unswitch-loops option have no effect?
On Mon, Aug 17, 2009 at 2:38 AM, ami_stuffami_st...@o2.pl wrote: Hi, I found out that when I use -fno-unswitch-loops option, it have no effect - loops are unswitched anyway: -O3 -fno-unswitch-loops Because of that to avoid -funswitch-loops optimization I must use something like this: -O2 -finline-functions -fpredictive-commoning -fgcse-after-reload -ftree-vectorize Is that a bug? Works fine for me. gcc.dg/tree-ssa/loop-6.c is unswitched with -O3 but not with -O3 -fno-unswitch-loops. You have to be more specific. Maybe PRE or if-conversion perform the unswichting for you. Richard. Tested with GCC 4.4.1 (m68k). Regards
Re: -fno-unswitch-loops option have no effect?
Hi, Works fine for me. gcc.dg/tree-ssa/loop-6.c is unswitched with -O3 but not with -O3 -fno-unswitch-loops. This one works for me too. Could you try to compile deflate.c from libz? Here are my results: -m68060 -O3 -fno-unswitch-loops - 12,9kb -m68060 -O3 - 12,9kb -m68060 -O2 -finline-functions -fgcse-after-reload -ftree-vectorize -fpredictive-commoning - 12,4kb but it's a lot more visible with libavcodec/dsputil.c from FFmpeg package: OPTFLAGS= -mnobitfield -m68060 -std=c99 -Wdeclaration-after-statement -Wdisabled-optimization -fno-math-errno -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-common -fomit-frame-pointer -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -Wcast-qual -Wwrite-strings -Wundef -O2 -finline-functions -fgcse-after-reload -ftree-vectorize -fpredictive-commoning: 306kb OPTFLAGS= -mnobitfield -m68060 -std=c99 -Wdeclaration-after-statement -Wdisabled-optimization -fno-math-errno -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-common -fomit-frame-pointer -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -Wcast-qual -Wwrite-strings -Wundef -O3 -fno-unswitch-loops: 1,18mb OPTFLAGS= -mnobitfield -m68060 -std=c99 -Wdeclaration-after-statement -Wdisabled-optimization -fno-math-errno -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-common -fomit-frame-pointer -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -Wcast-qual -Wwrite-strings -Wundef -O3 1,18mb Regards
Re: -fno-unswitch-loops option have no effect?
On 08/17/2009 02:32 PM, ami_stuff wrote: Hi, Works fine for me. gcc.dg/tree-ssa/loop-6.c is unswitched with -O3 but not with -O3 -fno-unswitch-loops. This one works for me too. Could you try to compile deflate.c from libz? Here are my results: -m68060 -O3 -fno-unswitch-loops - 12,9kb -m68060 -O3 - 12,9kb -m68060 -O2 -finline-functions -fgcse-after-reload -ftree-vectorize -fpredictive-commoning - 12,4kb And why do you think that loop unswitching has anything to do with the size growth? BTW, -O3 is not guaranteed to give better performance than -O2. Paolo
Re: -fno-unswitch-loops option have no effect?
Hi, Here are my results: -m68060 -O3 -fno-unswitch-loops - 12,9kb -m68060 -O3 - 12,9kb -m68060 -O2 -finline-functions -fgcse-after-reload -ftree-vectorize -fpredictive-commoning - 12,4kb And why do you think that loop unswitching has anything to do with the size growth? Shouldn't I get the same file sizes with: -m68060 -O3 -fno-unswitch-loops and -m68060 -O2 -finline-functions -fgcse-after-reload -ftree-vectorize -fpredictive-commoning ? I don't know, but I think the same optimalizations should be used in these cases, so file size should be the same. I'm wrong?
Re: -fno-unswitch-loops option have no effect?
On 08/17/2009 03:33 PM, ami_stuff wrote: -m68060 -O3 -fno-unswitch-loops and -m68060 -O2 -finline-functions -fgcse-after-reload -ftree-vectorize -fpredictive-commoning Some heuristics are tuned differently for -O2 and -O3. The only way to know is to look at the dumps. Paolo
Re: -fno-unswitch-loops option have no effect?
Hello ami_stuff On 17.08.09, you wrote: Hi, Hundreds and hundreds of people read this list, so every low-detail I think there may be a bug message you send wastes hours of other people's time. Ok, Ok, but if someone will reproduce the same problem on his system I can fill bugreport, otherwise I will only waste my time, hours of my time, to start detailed bugreport. Maybe this is only fault of my GCC's build? gcc 4 AOS 68k builds are build from offical gcc sourcetree and there are no changes If it *is* a bug, on the bug tracker, it will be picked up by people interested in that specific area It may takes months before someone will look at the bugreport. If it's really a bug IMHO it's a bit critical bug. though you don't seem to do much in-depth research, nor do you supply any detail of what you did and what you expected. There is no need for much detail, just compile any bigger sourcecode with -O3 -fno-.. and after that with -O2 When the object files are not identical, something is wrong and I can start a bug report. how much is size diffrent ? You use -finline-functions -fpredictive-commoning -fgcse-after-reload -ftree-vectorize right ? I see in Gcc source that there is more set on -O3. flag_ipa_cp_clone = opt3; if (flag_ipa_cp_clone) flag_ipa_cp = 1; .but i think you can easy test, compile the ffmpeg, if it give no internal compiler error with -fno then it work. here is from source opt.c what is set on opt3 opt3 = (optimize = 3); flag_predictive_commoning = opt3; flag_inline_functions = opt3; flag_unswitch_loops = opt3; flag_gcse_after_reload = opt3; flag_tree_vectorize = opt3; flag_ipa_cp_clone = opt3; if (flag_ipa_cp_clone) flag_ipa_cp = 1; Regards Regards
Re: -fno-unswitch-loops option have no effect?
Hi, gcc 4 AOS 68k builds are build from offical gcc sourcetree and there are no changes Yes, I know, but some problems may happens anyway like it happened before (problems with defines). I think if there is a problem the best is to compare GCCs from different sources. how much is size diffrent ? 306kb vs 1,18mb - dsputil.c .but i think you can easy test, compile the ffmpeg, if it give no internal compiler error with -fno then it work. I get the same ICE with -O3 and -O3 -fno-unswitch-loops - mpegvideo.c file. Regards
Re: -fno-unswitch-loops option have no effect?
On Aug 17, 2009, at 10:50 AM, Bernd Roesch wrote: [..] There is no need for much detail, just compile any bigger sourcecode with -O3 -fno-.. and after that with -O2 When the object files are not identical, something is wrong and I can start a bug report. how much is size diffrent ? You use -finline-functions -fpredictive-commoning -fgcse-after-reload -ftree-vectorize right ? I see in Gcc source that there is more set on -O3. flag_ipa_cp_clone = opt3; if (flag_ipa_cp_clone) flag_ipa_cp = 1; .but i think you can easy test, compile the ffmpeg, if it give no internal compiler error with -fno then it work. here is from source opt.c what is set on opt3 opt3 = (optimize = 3); flag_predictive_commoning = opt3; flag_inline_functions = opt3; flag_unswitch_loops = opt3; flag_gcse_after_reload = opt3; flag_tree_vectorize = opt3; flag_ipa_cp_clone = opt3; if (flag_ipa_cp_clone) flag_ipa_cp = 1; That doesn't cover all of it; for instance, complete loop unrolling increases code size more on -O3. That means you run into http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40992 with ffmpeg's asm enabled, but turning it down (--param max- completely-peel-times=2) actually seems slightly faster even with plain C on i386.
-fno-unswitch-loops option have no effect?
Hi, I found out that when I use -fno-unswitch-loops option, it have no effect - loops are unswitched anyway: -O3 -fno-unswitch-loops Because of that to avoid -funswitch-loops optimization I must use something like this: -O2 -finline-functions -fpredictive-commoning -fgcse-after-reload -ftree-vectorize Is that a bug? Tested with GCC 4.4.1 (m68k). Regards