Hi Sun,
I did some compile time measurement on two spec test cases (gcc and omentpp),
here is the time output for the make:
$ time 471.omnetpp.compile.sh # opencc -O0
real 6m59.678s
user 1m12.313s
sys 0m10.709s
$ time 471.omnetpp.compile.sh # opencc -O0 -Wb,-PHASE:p
real 9m14.919s
user 3m19.088s
sys 0m12.049s
$ time 471.omnetpp.compile.sh # opencc -O1
real 8m41.378s
user 1m36.750s
sys 0m12.277s
$ time 471.omnetpp.compile.sh #opencc -O2
real 9m34.647s
user 2m20.353s
sys 0m12.793s
$ time 471.omnetpp.compile.sh # gcc -O0
real 1m11.522s
user 0m33.450s
sys 0m4.172s
$ time 471.omnetpp.compile.sh # gcc -O1
real 1m20.740s
user 0m49.039s
sys 0m5.292s
$ time 471.omnetpp.compile.sh # gcc -O2
real 1m38.373s
user 1m1.136s
sys 0m4.484s
------
$ time 403.gcc.compile.sh # opencc -O0
real 12m24.815s
user 2m10.364s
sys 0m12.145s
$ time 403.gcc.compile.sh # opencc -O0 -Wb,-PHASE:p
real 14m6.916s
user 3m50.138s
sys 0m13.233s
$ time 403.gcc.compile.sh # opencc -O1
real 15m37.435s
user 3m9.724s
sys 0m15.549s
$ time 403.gcc.compile.sh # opencc -O2
real 19m38.656s
user 6m52.118s
sys 0m16.241s
$ time 403.gcc.compile.sh # gcc -O0
real 1m41.215s
user 0m40.803s
sys 0m3.728s
$ time 403.gcc.compile.sh # gcc -O1
real 2m54.200s
user 2m1.896s
sys 0m4.820s
$ time 403.gcc.compile.sh # gcc -O2
real 3m52.362s
user 2m58.151s
sys 0m5.028s
Two observations here:
1. the preopt at O0 is slower than -O1, the PreOptimizer turned on too much
components which are not needed for dead code elimination, and it seems there
is
no easy way to turn on CFG and DCE only.
2. opencc is much slower than gcc, especially the real time, which means we
spend most of time on IO. One unnecessary process is opencc uses gcc as
standalone preprocessor.
Maybe we should use the newly added WHIRL CFG to build a WHIRL node DCE, that
will be much light weighted than PreOPT. What is your opinion?
Thanks,
-Xiaohua
________________________________
From: Sun Chan <sun.c...@gmail.com>
To: "Gilmore, Doug" <doug.gilm...@amd.com>
Cc: Xiaohua Zhang <xiaohua_zh...@yahoo.com>;
"open64-devel@lists.sourceforge.net" <open64-devel@lists.sourceforge.net>
Sent: Fri, February 11, 2011 5:54:27 PM
Subject: Re: [Open64-devel] should we close bug588 as user error?
Thx!
We should also compare the compile time for building the kernel with
and without this option. It should help open64 compile time since O2
is needed at this point. OTOH, I am curious the time compared to gcc
Sun
On Sat, Feb 12, 2011 at 9:51 AM, Gilmore, Doug <doug.gilm...@amd.com> wrote:
> Sun's experiment worked for me:
>
> $ opencc -O0 -Wb,-PHASE:p,-tf3,-tra bug588-1.c -c -keep
> $ grep -i preopt bug588-1.t
> ========== Driver dump after PREOPT ==========
> $ opencc -O0 -Wb,-tf3,-tra bug588-1.c -c -keep
> bug588-1.s: Assembler messages:
> bug588-1.s:63: Error: Incorrect register `%rax' used with `l' suffix
> $ grep -i preopt bug588-1.t
> $
>
> Doug
>> -----Original Message-----
>> From: Sun Chan [mailto:sun.c...@gmail.com]
>> Sent: Friday, February 11, 2011 5:30 PM
>> To: Xiaohua Zhang
>> Cc: open64-devel@lists.sourceforge.net
>> Subject: Re: [Open64-devel] should we close bug588 as user error?
>>
>> this is strange. Can you do a trace and see why? -tt25:0xffffffff (or
>> just turn on dce trace)
>> Sun
>>
>> 2011/2/12 Xiaohua Zhang <xiaohua_zh...@yahoo.com>:
>> > Hi Sun,
>> >
>> > The -phase:p option seems doesn't make things any better, it still
>> reports
>> > the same error message.
>> >
>> > -Xiaohua
>> >
>> > ________________________________
>> > From: Sun Chan <sun.c...@gmail.com>
>> > To: C. Bergström <cbergst...@pathscale.com>
>> > Cc: open64-devel@lists.sourceforge.net
>> > Sent: Fri, February 11, 2011 3:08:01 PM
>> > Subject: Re: [Open64-devel] should we close bug588 as user error?
>> >
>> > this issue has come up multiple times, even for other compilers in
>> > another large company. Its about being able to build Linux at all opt
>> > levels.
>> >
>> > Xiaohua,
>> > can you do an experiment, please use the following options "-O0
>> > -phase:p" and see if the compile will go through.
>> > Thx!
>> >
>> > Sun
>> >
>> > 2011/2/12 "C. Bergström" <cbergst...@pathscale.com>:
>> >> Suneel Jain wrote:
>> >>> I thought that this reliance on the compiler doing dead code
>> >>> elimination at all optimization levels is all over the Linux
>> >>> kernel code.
>> >>>
>> >>> My recommendation would be to do this kind of dead code
>> >>> elimination at -O0 in Open64. That will provide greater
>> compatibility
>> >>> with gcc.
>> >>>
>> >> Is there any benefit outside of gcc compatibility? What are the
>> >> disadvantages? This broadly impacts *all* code that is/will be
>> built
>> >> with -O0 over 1 bad line of code. Someone should make a concise and
>> >> clear decision about at which point compatibility makes sense. This
>> >> seems like a knee jerk decision
>> >>
>> >>
>> >> --------------------------------------------------------------------
>> ----------
>> >> The ultimate all-in-one performance toolkit: Intel(R) Parallel
>> Studio XE:
>> >> Pinpoint memory and threading errors before they happen.
>> >> Find and fix more than 250 security defects in the development
>> cycle.
>> >> Locate bottlenecks in serial and parallel code that limit
>> performance.
>> >> http://p.sf.net/sfu/intel-dev2devfeb
>> >> _______________________________________________
>> >> Open64-devel mailing list
>> >> Open64-devel@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/open64-devel
>> >>
>> >
>> > ---------------------------------------------------------------------
>> ---------
>> > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio
>> XE:
>> > Pinpoint memory and threading errors before they happen.
>> > Find and fix more than 250 security defects in the development cycle.
>> > Locate bottlenecks in serial and parallel code that limit
>> performance.
>> > http://p.sf.net/sfu/intel-dev2devfeb
>> > _______________________________________________
>> > Open64-devel mailing list
>> > Open64-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/open64-devel
>> >
>> >
>>
>> -----------------------------------------------------------------------
>> -------
>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio
>> XE:
>> Pinpoint memory and threading errors before they happen.
>> Find and fix more than 250 security defects in the development cycle.
>> Locate bottlenecks in serial and parallel code that limit performance.
>> http://p.sf.net/sfu/intel-dev2devfeb
>> _______________________________________________
>> Open64-devel mailing list
>> Open64-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/open64-devel
>
>
>
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
