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 > ------------------------------------------------------------------------------ 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
