Hi,

  Could a gatekeeper please help review the fix for bug953(
http://bugs.open64.net/show_bug.cgi?id=953<http://bugs.open64.net/show_bug.cgi?id=952>
)?

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.
<http://bugs.open64.net/attachment.cgi?id=511>
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

Reply via email to