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
