why don't you bite the bullet and figure out why you got that assertion. I used your same reasoning and conclude that you should always do -O0 and you have no answer. Sun
On Mon, Mar 5, 2012 at 9:54 PM, Gang Yu <yugang...@gmail.com> wrote: > Some reasons to defend the fix suggestion: > > a.) it's a bug due to aggressive scheduling under inappropriate context, > disable the scheduling may fix the bug. > b.) Other two approaches may fix the bug: > b.1) improved heuristic on pre-allocation scheduling like other compilers > do, but we haven't done that, before we get a better solution, we can get > temporay solution and track this problem further. > b.2) enhancing the register allocation algorithm to get a spill for the > register that unable to spill. The is not preferrable since the LRA has > served as the production algorithm for a long time, changes to the grand > algorithmx need plenty of tests and carefully verification. Even we get that > TN170 spilled, this is still not good, since the code is scheduled, but also > introduced more spills lead to the performance regression. > c.) some optimizations are not good for some architectures, for example, x86 > does not employ the Register Variable Identification(RVI) phase in WOPT > which will obviously increase the register pressures. So, shall we still > apply aggressive preallocation scheduling for IA32 ,PIC which is with very > limited register set? > > Thanks > > Regards > Gang > > > On Fri, Feb 24, 2012 at 8:18 PM, Sun Chan <sun.c...@gmail.com> wrote: >> >> this is not a fix, you might as well say, always do -O0 and you can >> close 99% of a lot of optimization bugs >> Sun >> >> On Fri, Feb 24, 2012 at 3:56 PM, Gang Yu <yugang...@gmail.com> wrote: >> > Hi, >> > >> > Could a gatekeeper please help review the fix for >> > bug953(http://bugs.open64.net/show_bug.cgi?id=953)? >> > >> > Cut-down case please have a look at the attachment: >> > >> > http://bugs.open64.net/attachment.cgi?id=512 >> > >> > openCC -S bug953.cpp -fpic -m32 -O2 >> > >> > ### Assertion failure at line 4678 of >> > /fc/home/yug/open64/osprey/be/cg/lra.cxx: >> > ### Compiler Error in file bug953.cpp during Local Register Allocation >> > phase: >> > ### LRA: Unable to spill TN:170 (cl:1) in BB:1, GRA grant:3 >> > openCC INTERNAL ERROR: >> > /fc/home/yug/target/x86_64_dbg/lib/gcc-lib/x86_64-open64-linux/5.0/be >> > returned non-zero status 1 >> > >> > Analysis: >> > >> > Dump of the failed bb before the LRA is: >> > >> > [ 762, 0] TN154 :- ld32 GTN4(%rsp) (sym:bufSize+0) ; WN id:23 >> > bufSize+0x0 >> > [ 762, 0] TN156 :- ld32 GTN4(%rsp) (sym:imageSize+0) ; WN id:27 >> > imageSize+0x0 >> > [ 0, 0] TN159 :- zero32 ; >> > [ 759, 1] TN149 :- ld32 GTN4(%rsp) (sym:buffer+0) ; WN id:24 buffer+0x0 >> > [ 763, 1] TN164 :- ldc32 (0x1) ; >> > [ 761, 1] TN152 :- ldc32 (0x12345678) ; >> > [ 759, 2] TN150 :- ldc32 (0x2) ; >> > [ 762, 3] TN157 :- lea32 TN154 (0xffffffffffffffe0) ; >> > [ 762, 5] TN155 TN158 :- div32 TN156 TN159 TN157 ; >> > [ 763, 8] :- store8 TN164 TN149 (0x8) ; WN id:29 >> > [ 761, 8] :- store32 TN152 TN149 (0x2) ; WN id:26 >> > [ 759, 8] :- store16 TN150 TN149 (0x0) ; WN id:25 >> > [ 762,23] TN33(%rflags) :- test32 TN158 TN158 ; >> > [ 762,24] TN161 :- setne TN33(%rflags) ; >> > [ 762,25] TN160 :- movzbl TN161 ; >> > [ 762,26] TN162 :- leax32 TN160 TN155 (0x1) (0x0) ; >> > [ 762,28] TN163 :- lea32 TN162 (0x1) ; >> > [ 762,30] :- store16 TN163 TN149 (0x6) ; WN id:28 >> > [ 764,30] :- store32 TN154 GTN4(%rsp) (0x4) ; WN id:31 >> > [ 764,30] :- store32 TN149 GTN4(%rsp) (0x0) ; WN id:30 >> > [ 764,31] :- call (sym:_ZN7factory14checksumPacketEPNS_10rbu_packetEj+0) >> > ; >> > WN >> > >> > while before the IGLS_Schedule_Region, we can get >> > >> > [ 759, 0] TN149 :- ld32 GTN4(%rsp) (sym:buffer+0) ; WN id:24 buffer+0x0 >> > [ 759, 0] TN150 :- ldc32 (0x2) ; >> > [ 759, 0] :- store16 TN150 TN149 (0x0) ; WN id:25 >> > [ 761, 0] TN152 :- ldc32 (0x12345678) ; >> > [ 761, 0] :- store32 TN152 TN149 (0x2) ; WN id:26 >> > [ 762, 0] TN154 :- ld32 GTN4(%rsp) (sym:bufSize+0) ; WN id:23 >> > bufSize+0x0 >> > [ 762, 0] TN156 :- ld32 GTN4(%rsp) (sym:imageSize+0) ; WN id:27 >> > imageSize+0x0 >> > [ 762, 0] TN157 :- lea32 TN154 (0xffffffffffffffe0) ; >> > [ 0, 0] TN159 :- zero32 ; >> > [ 762, 0] TN155 TN158 :- div32 TN156 TN159 TN157 ; >> > [ 762, 0] TN33(%rflags) :- test32 TN158 TN158 ; >> > [ 762, 0] TN161 :- setne TN33(%rflags) ; >> > [ 762, 0] TN160 :- movzbl TN161 ; >> > [ 762, 0] TN162 :- leax32 TN160 TN155 (0x1) (0x0) ; >> > [ 762, 0] TN163 :- lea32 TN162 (0x1) ; >> > [ 762, 0] :- store16 TN163 TN149 (0x6) ; WN id:28 >> > [ 763, 0] TN164 :- ldc32 (0x1) ; >> > [ 763, 0] :- store8 TN164 TN149 (0x8) ; WN id:29 >> > [ 764, 0] :- store32 TN149 GTN4(%rsp) (0x0) ; WN id:30 >> > [ 764, 0] :- store32 TN154 GTN4(%rsp) (0x4) ; WN id:31 >> > [ 764, 0] :- call (sym:_ZN7factory14checksumPacketEPNS_10rbu_packetEj+0) >> > ; >> > WN >> > >> > For the scheduling consideration, this is good since constants and loads >> > TNs >> > are lifted to the head , dependency between adjacent registers are >> > reduced. >> > However, this increase the register pressures and under m32, fpic , the >> > physical registers are very limited (EBX used as GOT indexing dedicate >> > register) which cause the final TN170 unable to get a physical register. >> > >> > Suggested patch: >> > >> > disable IGLS_scheduling under m32 , PIC environment. >> > >> > index 9e644f8..a3c978a 100644 >> > --- a/osprey/be/cg/cg.cxx >> > +++ b/osprey/be/cg/cg.cxx >> > @@ -1505,7 +1505,14 @@ extern void Generate_Return_Address(void); >> > GRA_LIVE_Rename_TNs(); >> > } >> > #if !defined(TARG_PPC32) // PPC IGLS_Schedule_Region bugs >> > +#ifdef TARG_X8664 >> > + // open64.net bug953. disable IGLS_Schedule_Region under >> > + // -m32,-fpic environment. >> > + if (!(Is_Target_32bit() && Gen_PIC_Shared)) >> > + IGLS_Schedule_Region (TRUE /* before register allocation */); >> > +#else >> > IGLS_Schedule_Region (TRUE /* before register allocation */); >> > +#endif >> > #ifdef TARG_X8664 >> > Examine_Loop_Info("after prescheduling", TRUE); >> > void Counter_Merge (char*); >> > >> > TIA for review. >> > >> > Regards >> > Gang >> > >> > >> > ------------------------------------------------------------------------------ >> > Virtualization & Cloud Management Using Capacity Planning >> > Cloud computing makes use of virtualization - but cloud computing >> > also focuses on allowing computing to be delivered as a service. >> > http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> > _______________________________________________ >> > Open64-devel mailing list >> > Open64-devel@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/open64-devel >> > > > ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
