malcolm3141

OpenCL compilation redundancy

Discussion created by malcolm3141 on Feb 24, 2010
Latest reply on Feb 25, 2010 by MicahVillmow

When compiling code using the convert_int4(uchar4) function, I get rather redundant GPU assembly from it. Compiling this:

 

 

uchar4 b = ...;

int4 c0 = convert_int4(b) << 4;

 

c0 += (int4)(1, 2, 3, 4);


Becomes this:


01 TEX: ADDR(160) CNT(1) 

     10  VFETCH R0.x___, R0.y, fc156  MEGA(4) 

         FETCH_TYPE(NO_INDEX_OFFSET) 

02 ALU: ADDR(56) CNT(89) 

     11  x: ASHR        ____,  R0.x,  (0x00000010, 2.242077543e-44f).x      

         y: ASHR        ____,  R0.x,  (0x00000008, 1.121038771e-44f).y      

         z: MOV         ____,  R0.x      

         w: ASHR        ____,  R0.x,  (0x00000018, 3.363116314e-44f).z      

     12  x: LSHL        ____,  PV11.x,  (0x00000018, 3.363116314e-44f).x      

         y: LSHL        ____,  PV11.w,  (0x00000018, 3.363116314e-44f).x      

         z: LSHL        ____,  PV11.y,  (0x00000018, 3.363116314e-44f).x      

         w: LSHL        ____,  PV11.z,  (0x00000018, 3.363116314e-44f).x      

     13  x: ASHR        ____,  PV12.x,  (0x00000018, 3.363116314e-44f).x      

         y: ASHR        ____,  PV12.y,  (0x00000018, 3.363116314e-44f).x      

         z: ASHR        ____,  PV12.z,  (0x00000018, 3.363116314e-44f).x      

         w: ASHR        ____,  PV12.w,  (0x00000018, 3.363116314e-44f).x      

     14  x: AND_INT     ____,  PV13.x,  (0x000000FF, 3.573311084e-43f).x      

         y: AND_INT     ____,  PV13.y,  (0x000000FF, 3.573311084e-43f).x      

         z: AND_INT     ____,  PV13.z,  (0x000000FF, 3.573311084e-43f).x      

         w: AND_INT     ____,  PV13.w,  (0x000000FF, 3.573311084e-43f).x      

     15  x: LSHL        ____,  PV14.x,  (0x00000018, 3.363116314e-44f).x      

         y: LSHL        ____,  PV14.y,  (0x00000018, 3.363116314e-44f).x      

         z: LSHL        ____,  PV14.z,  (0x00000018, 3.363116314e-44f).x      

         w: LSHL        ____,  PV14.w,  (0x00000018, 3.363116314e-44f).x      

     16  x: ASHR        ____,  PV15.x,  (0x00000018, 3.363116314e-44f).x      

         y: ASHR        ____,  PV15.y,  (0x00000018, 3.363116314e-44f).x      

         z: ASHR        ____,  PV15.z,  (0x00000018, 3.363116314e-44f).x      

         w: ASHR        ____,  PV15.w,  (0x00000018, 3.363116314e-44f).x      

     17  x: LSHL        ____,  PV16.x,  (0x00000018, 3.363116314e-44f).x      

         y: LSHL        ____,  PV16.z,  (0x00000018, 3.363116314e-44f).x      

         z: LSHL        ____,  PV16.y,  (0x00000018, 3.363116314e-44f).x      

         w: LSHL        ____,  PV16.w,  (0x00000018, 3.363116314e-44f).x      

     18  x: LSHR        ____,  PV17.x,  (0x00000018, 3.363116314e-44f).x      

         y: LSHR        ____,  PV17.y,  (0x00000018, 3.363116314e-44f).x      

         z: LSHR        ____,  PV17.w,  (0x00000018, 3.363116314e-44f).x      

         w: LSHR        ____,  PV17.z,  (0x00000018, 3.363116314e-44f).x      

     19  x: LSHL        ____,  PV18.x,  (0x00000004, 5.605193857e-45f).x      

         y: LSHL        ____,  PV18.w,  (0x00000004, 5.605193857e-45f).x      

         z: LSHL        ____,  PV18.y,  (0x00000004, 5.605193857e-45f).x      

         w: LSHL        ____,  PV18.z,  (0x00000004, 5.605193857e-45f).x      

 

 

     20  x: ADD_INT     ____,  PV19.x,  (0x00000003, 4.203895393e-45f).x      

         y: ADD_INT     ____,  PV19.y,  (0x00000004, 5.605193857e-45f).y      

         z: ADD_INT     ____,  PV19.z,  (0x00000002, 2.802596929e-45f).z      

         w: ADD_INT     ____,  PV19.w,  1      

 

You can see that the conversion is actually complete after executing 11, 12, and 13 (if 13 was LSHR). The instructions for 14 - 18 are redundant.


Also, on a separate topic, why are 24bit integer instructions not exposed in IL. Am I correct in believing 32bit multiplies are restricted to the t pipe, but 24bit can go in x,y,z,w pipe? If so, then using mad24(...) and mul24(...) could provide some significant efficiencies!


Malcolm

 



Outcomes