HKG15-405: Redundant zero/sign-extension elimination in GCC --------------------------------------------------- Speaker: Kugan Vivekanandarajah Date: February 12, 2015 --------------------------------------------------- ★ Session Summary ★ Several instances of redundant zero/sign-extension related bugs are reported in GCC and Linaro bugzilla. These bugs are sources of performance/code size penalties. This presentation will discuss the history, design considerations, implementation, and performance characteristics of redundant zero/sign extension elimination in GCC. We will then discuss a new compiler pass that performs computation in promoted type mode in such a way that removes redundant zero/sign-extensions. -------------------------------------------------- ★ Resources ★ Pathable: https://hkg15.pathable.com/meetings/250833 Video: https://www.youtube.com/watch?v=JkTkmGe3tms Etherpad: http://pad.linaro.org/p/hkg15-405 --------------------------------------------------- ★ Event Details ★ Linaro Connect Hong Kong 2015 - #HKG15 February 9-13th, 2015 Regal Airport Hotel Hong Kong Airport --------------------------------------------------- http://www.linaro.org http://connect.linaro.org

1. Presented by
Date
Event
HKG15-405: Redundant
zero/sign-extension
elimination in GCC
Kugan Vivekanandarajah
Linaro Toolchain Working Group
February 12, 2015
Linaro Connect HKG15

2. Overview
● What is zero/sign extension
● Why GCC generates zero/sign extensions
● How GCC minimizes redundant zero/sign extensions
● Shortcomings in current approach
● Using value range (VR) to remove redundant
extensions
● Register promotion / widening computations to remove
redundant extensions
● Conclusion

3. Zero/sign extension operation
● zero-extend extends unsigned values to wider mode
● sign-extend extends signed values to wider mode

4. Zero/sign extension instructions
in AArch32 and AArch64
● Explicit extend instructions
○ SXTB Sign-extend byte/UXTB Unsigned extend byte
○ SXTH Sign-extend halfword/UXTH Unsigned extend halfword
● Extend operations as part of other instructions
○ The extended register instructions provide an optional sign-extension
or zero-extension (in AArch64)
■ ADD X1, X2, W3, UXTB #2
○ Modern CPUs may take an extra cycle to perform an ALU-with-shift
type operation
● Load and extend are also combined
○ ldb/ldh effectively does extension

5. Why extensions are needed
● Extensions are part of ABI
○ aapcs32 : "A Fundamental Data Type that is smaller than 4 bytes is
zero-or sign-extended to a word and returned in r0"
○ aapcs64 : "When an argument is assigned to a register any unused
bits in the register have unspecified value."
char foo (char val1, char
val2)
{
return val1 + val2;
}
aarch32:
foo:
add r0, r0, r1
uxtb r0, r0
bx lr
aarch64:
foo:
uxtb w1, w1
add w0, w1, w0, uxtb
ret

6. Why extensions are needed
● Conversion between types
○ ABI difference between aarch32 and aarch64 means extension is in
different places for this simple example
char foo (int ch)
{
return ch;
}
int bar (char ch)
{
return ch;
}
aarch32:
foo:
uxtb r0, r0
bx lr
bar:
bx lr
aarch64:
foo:
ret
bar:
uxtb w0, w0
ret

7. Redundant extensions in GCC
● SUBREG and extensions are generated while
converting from tree to RTL
○ Type conversions
○ Some of the extensions may be redundant
● Subsequent passes remove/optimize redundant
extensions
○ combine - combines it to a single instruction
○ ree - redundant extension elimination pass
○ RTX simplifications
■ With SRP_SIGNED and SRP_UNSIGNED

8. Combine example (AArch64)
● Combines zero/sign-extension with the use if target has support
● Not zero/sign-extension specific but helps here
● Works only within basic-blocks
void bar (int *ch,
char a)
{
*ch = *ch + a;
}
3: r77:SI=zero_extend(x1:QI)
8: r78:SI=r79:SI+r77:SI
8: r78:SI=zero_extend(x1:QI)+r79:SI
add w1, w2, w1, uxtb
Combines to

9. ree pass (Enabled for AArch64)
● Moves extension to definition of extension src
○ If md supports such instruction
● Runs after register allocation
○ Does not help in reducing register pressure
● Combines reaching definition
○ Not reaching single use
○ ABI mandated extension of parameters for aarch64 cannot be
combined (i.e. extension of parameter followed by use expression)
11: x19:HI=x0:HI
13: x1:DI=x20:DI
14: x0:DI=x21:DI
15: x0:HI=call [`calc_func'] argc:0
19: x19:SI=sign_extend(x19:HI)
11: x19:SI=sign_extend(x0:HI)
13: x1:DI=x20:DI
14: x0:DI=x21:DI
15: x0:HI=call [`calc_func'] argc:0

10. Shortcomings in current
approach
● Challenges in removing redundant extensions in RTL
○ Combine with other patterns (to generate single instruction) has its
limits
○ Simplification of SUBREG does not have all the information in RTL
■ Relies on SRP_SIGNED and SRP_UNSIGNED
■ Sign information is lost in RTL making it hard to remove some
redundant extensions
● What can we do?
○ Provide additional information to RTL
○ Change the tree such that extensions are minimized when converting
to RTL

11. Using value range to remove
redundant extensions
● Value range is used to annotate RTL SUBREG with
SRP_SIGNED_AND_UNSIGNED
○ Extension at RTL level will be redundant and optimized away when
this is true
● Example
○ _6 = (short int) _5;
○ Value range of _6: [3, 10]
(insn 13 12 0 (set (reg:SI 73 [ D.2640 ])
(sign_extend:SI (subreg:HI (reg:SI 81) 0))) t.c:6 -1
(nil))
○ Value range of _6 means reg:SI 81 is already sign and zero extended
(SRP_SIGNED_AND_UNSIGNED)

12. Example
short foo (unsigned char c)
{
c = c & (unsigned char)
0x0F;
if (c > 7)
return ((short)(c - 5));
else
return ((short)c);
}
foo:
and w0, w0, 15
cmp w0, 7
bhi .L5
sxth w0, w0
ret
.p2align 3
.L5:
sub w0, w0, #5
sxth w0, w0
ret
foo:
and w0, w0, 15
cmp w0, 7
bhi .L5
ret
.p2align 3
.L5:
sub w0, w0, #5
ret

13. VRP Dump @ tree level RTL expansion using VRP Normal RTL Expansion
short foo (unsigned char c)
{
c = c & (unsigned char)
0x0F;
if (c > 7)
return ((short)(c - 5));
else
return ((short)c);
}
c_3: [0, 15]
_4: [8, 15]
_6: [3, 10]
_7: [0, 7]
<bb 2>:
c_3 = c_2(D) & 15;
if (c_3 > 7)
goto <bb 3>;
else
goto <bb 4>;
<bb 3>:
_4 = (unsigned short) c_3;
_5 = _4 + 65531;
_6 = (short int) _5;
goto <bb 5>;
<bb 4>:
_7 = (short int) c_3;
<bb 5>:
# _1 = PHI <_6(3), _7(4)>
return _1;
2:r78:SI=zero_extend(x0:QI)
6: r79:SI=r78:SI&0xf
7: r74:SI=r79:SI
8: cc:CC=cmp(r74:SI,0x7)
9: pc={(leu(cc:CC,0))?L16:pc}
REG_BR_PROB 6100
11: r80:HI=r74:SI#0
12: r81:SI=r80:HI#0-0x5
13: r73:SI=r81:SI
14: pc=L19
15: barrier
16: L16:
18: r73:SI=r74:SI
19: L19:
20: 21: r77:HI=r73:SI#0
25: x0:HI=r77:HI
26: use x0:HI
r78:SI=zero_extend(x0:QI)
6: r79:SI=r78:SI&0xf
7:r74:SI=zero_extend(r79:SI#0)
8:cc:CC=cmp(r74:SI,0x7)
9:pc={(leu(cc:CC,0))?L16:pc}
REG_BR_PROB 6100
11: r80:HI=r74:SI#0
12: r81:SI=r80:HI#0-0x5
13:r73:SI=sign_extend(r81:SI#0)
14: pc=L19
15: barrier
16: L16:
18:r73:SI=sign_extend(r74:SI#0)
19: L19:
20: r77:HI=r73:SI#0
25: x0:HI=r77:HI
26: use x0:HI

14. Challenges
● Value ranges propagated are for the type of SSA_NAME
○ If the operation can WRAP, higher bits in PROMOTE_MODE can be
unpredictable
○ Additional WRAP attribute is needed
○ Example (on alpha where register width is 64 bit and _344 is 32 bit
unsigned variable):
_343 = ivtmp.179_52 + 2147483645; [0x80000004, 0x800000043]
_344 = _343 * 2; [0x8, 0x86]
_345 = (integer(kind=4)) _344; [0x8, 0x86]
● Value ranges propagated are pessimistic at times
○ Unlike our case, most value range based optimizations are done in
VRP pass itself and have more precise data

15. Register promotion in tree to
remove redundant extensions
● Promote operations to word mode such that SUBREG
and extensions are minimized in RTL
● Fix-up (conversions) are still needed
○ to preserve the semantics of the program
;; c_3 = c_2(D) & 15; // char type
(insn 6 5 7 (set (reg:SI 116)
(and:SI (reg/v:SI 115 [ c ])
(const_int 15 [0xf]))) t.c:3 -1
(nil))
(insn 7 6 0 (set (reg/v:SI 111 [ c ])
(zero_extend:SI (subreg:QI (reg:SI 116) 0))) t.c:3 -1 (nil))
;; c_3 = c_2(D) & 15; // int type
(insn 6 5 0 (set (reg/v:SI 111 [ c ])
(and:SI (reg/v:SI 115 [ c ])
(const_int 15 [0xf]))) t.c:3 -1
(nil))

16. short foo (unsigned char c)
{
c = c & (unsigned char)0x0F;
if (c > 7)
return ((short)(c - 5));
else
return ((short)c);
}
foo (unsigned char c)
{
short int _1;
unsigned short _4;
unsigned short _5;
short int _6;
short int _7;
<bb 2>:
c_3 = c_2(D) & 15;
if (c_3 > 7)
goto <bb 3>;
else
goto <bb 4>;
<bb 3>:
_4 = (unsigned short) c_3;
_5 = _4 + 65531;
_6 = (short int) _5;
goto <bb 5>;
<bb 4>:
_7 = (short int) c_3;
<bb 5>:
# _1 = PHI <_6(3), _7(4)>
return _1;
}
foo (unsigned int c)
{
int _5, _6, _7;
unsigned int _4, _9, _10;
short int _11;
<bb 2>:
c_3 = c_2(D) & 15;
if (c_3 > 7)
goto <bb 3>;
else
goto <bb 4>;
<bb 3>:
_10 = (unsigned int) c_3;
_4 = _10 + 4294967291;
_9 = _4 & 65535;
_5 = (int) _9;
goto <bb 5>;
<bb 4>:
_6 = (int) c_3;
<bb 5>:
# _7 = PHI <_5(3), _6(4)>
_11 = (short int) _7;
return _11;
}

17. Example
short foo (unsigned char c)
{
c = c & (unsigned char)
0x0F;
if (c > 7)
return ((short)(c - 5));
else
return ((short)c);
}
foo:
and w0, w0, 15
cmp w0, 7
bhi .L5
sxth w0, w0
ret
.p2align 3
.L5:
sub w0, w0, #5
sxth w0, w0
ret
foo:
and w0, w0, 15
cmp w0, 7
bhi .L5
ret
.p2align 3
.L5:
sub w0, w0, #5
ret

18. Challenges
● Inserting fix-ups and conversions to preserve
semantics of the program
● Making subsequent passes optimize
redundancies

19. Conclusion
● Redundant zero/sign extension results in performance
and code size penalty
○ Excess instructions
○ Increased register pressure
● Removing redundant zero/sign extension is a challenge
and has to be approached from multiple levels.
● Patches for the discussed optimizations are currently
being reviewed/upstreamed.