Make Your PL/I and C/C++ Code Fly With the Right Compiler Options Peter Elderon IBM March, 2015 Insert Custom Session QR if Desired. WHAT … • does good application performance mean to you? • Fast Execution Time • Short Compile Time 3 HOW … • to achieve good application performance? • Install New Hardware • Utilize Compiler Options • Code for Performance 4 Install New Hardware • Can make your code run faster • Requires NO • Recompilation • Relinking • Migration to new release • BUT, are you taking full advantage of all the new features from the new hardware? • i.e. the full ROI on the new piece of hardware 5 6 Utilize Compiler Options • Allows the compiler to exploit the hardware: • ARCH • HGPR • FLOAT(AFP) • Balance between compile-time vs. execution-time: • OPT(2) • OPT(3) • HOT [C/C++] • IPA [C/C++] • PDF 7 Utilize Compiler Options (cont’d) • Provide the details about the source or environment: • C/C++: • ANSIALIAS • IGNERRNO • LIBANSI • NOTHREADED • NOSTRICT • STRICT_INDUCTION • XPLINK • PL/I: • REDUCE • RESEXP • RULES(NOLAXCTL) • DEFAULT(CONNECTED REORDER NOOVERLAP) 8 Utilize Compiler Options (cont’d) • Controls load module size: • COMPACT [C/C++] • INLINE [C/C++] • DEFAULT(INLINE) [PL/I] • UNROLL 9 ARCHitecture Option • The ARCH option specifies the level of the hardware on which the generated code must run • C/C++ default is ARCH(7) for V2R1 and up • PL/I default is ARCH(7) for 4.5 and up • produces code that will run on z9 (or later) machines • LE 2.1 requires z9 (or later) machines • However: you must set ARCH to the lowest level machine where your generated code will run • If you specify ARCH(n) and run the generated code on an ARCH(n-1) machine, you will most likely get an operation exception 10 ARCHitecture - Timeline z10: Compare and Branch, Prefetch, Add Logical with Signed Immediate z9: z990, z890: Extended immediate, Extended translation, 11 Long displacement, 10 Load Byte … Decimal Floating point 9 z900, z800 – z900, z800 – ESA/390 mode: z/Architecture: Out-Of Order Support for LP64 support G5, G6: (OOO) pipeline 32-bit add/ 8 12-Additional subtract with Floating Point G2, G3, G4: carry/borrow 7 registers Support for 6 ARCH(11): Support for branch 5 IEEE Floating zEC13: relative G1: Point Vector instructions Support for string z/Architecture DFP-Packed Conversions operation h/w 4 ARCH(10): instruction zEC12, zBC12: all models 3 ARCH(9) DFP-Zoned Conversions, z196, z114: Transaction Execution 2 Load/store on condition, 1 Non-destructive ops, High- word 0 11 ARCH(9): Load/store on condition consider this small program: 2.0 | test: proc returns( fixed bin(31) ); 3.0 | 4.0 | exec sql include sqlca; 5.0 | 6.0 | dcl c fixed bin(31); 7.0 | 8.0 | exec sql commit; 9.0 | 10.0 | if sqlcode = 0 then 11.0 | c = 0; 12.0 | else 13.0 | c = -1; 14.0 | 15.0 | return( c ); 16.0 | end; 12 ARCH(9): Load/store on condition • Under OPT(3) ARCH(8), the instructions after the call are: 13 ARCH(9): Load/store on condition • under OPT(3) ARCH(9), the instructions after the call are: 14 ARCH(9): Load/store on condition • So, under ARCH(8), the code sequence was: – Load SQLCODE into r0 – Load -1 into r1 – Compare r0 (SQLCODE) with 0 and branch if NE to @1L8 – Load 0 into r1 – @1L8 – Store r1 into the return value • While under ARCH(9), the code sequence has no label and no branch: – Load -1 into r1 – Load SQLCODE into r0 via ICM (so that CC is set) – Load 0 into r0 – Load-on-condition r1 with r0 if the CC is zero (i.e. if SQLCODE = 0) – Store r1 into the return value 15 ARCH(10): DFP Zoned Conversion Facility • This code converts a PICTURE array to FIXED BIN pic2int: proc( ein, aus ) options(nodescriptor); dcl ein(0:100_000) pic'(9)9' connected; dcl aus(0:hbound(ein)) fixed bin(31) connected; dcl jx fixed bin(31); do jx = lbound(ein) to hbound(ein); aus(jx) = ein(jx); end; end; 16 ARCH(10): DFP Zoned Conversion Facility • Under ARCH(9), the heart of the loop consists of these 8 instructions 0058 F248 D098 1000 PACK #pd580_1(5,r13,152),_shadow2(9,r1,0) 005E C020 0000 0021 LARL r2,F'33' 0064 D204 D0A0 D098 MVC #pd581_1(5,r13,160),#pd580_1(r13,152) 006A 4110 1009 LA r1,#AMNESIA(,r1,9) 006E D100 D0A4 200C MVN #pd581_1(1,r13,164),+CONSTANT_AREA(r2,12) 0074 F874 D0A8 D0A0 ZAP #pd582_1(8,r13,168),#pd581_1(5,r13,160) 007A 4F20 D0A8 CVB r2,#pd582_1(,r13,168) 007E 502E F000 ST r2,_shadow1(r14,r15,0) 17 ARCH(10): DFP Zoned Conversion Facility • While under ARCH(10), it consists of 9 instructions and uses DFP in several of them – but since only the ST and the new CDZT refer to storage, the loop runs more than 66% faster 0060 EB2F 0003 00DF SLLK r2,r15,3 0066 B9FA 202F ALRK r2,r15,r2 006A A7FA 0001 AHI r15,H'1' 006E B9FA 2023 ALRK r2,r3,r2 0072 ED08 2000 00AA CDZT f0,#AddressShadow(9,r2,0),b'0000' 0078 B914 0000 LGFR r0,r0 007C B3F6 0000 IEDTR f0,f0,r0 0080 B941 9020 CFDTR r2,b'1001',f0 0084 5021 E000 ST r2,_shadow1(r1,r14,0) 18 ARCH(11): Vector Instruction Facility • This simple code that tests if a UTF-16 string is numeric wnumb: proc( s ); dcl s wchar(*) var; dcl n wchar value( '0123456789' ); dcl sx fixed bin(31); sx = verify( s, n ); if sx > 0 then ... • Is done with an expensive library call with ARCH <= 10 19 ARCH(11): Vector Instruction Facility • With ARCH(11), the vector instruction facility is used to inline it as E700 E000 0006 VL v0,+CONSTANT_AREA(,r14,0) E740 E010 0006 VL v4,+CONSTANT_AREA(,r14,16) @1L2 DS 0H A74E 0010 CHI r4,H'16' 4150 0010 LA r5,16 B9F2 4054 LOCRL r5,r4 B9FA F0E2 ALRK r14,r2,r15 E725 E000 0037 VLL v2,r5,_shadow1(r14,0) E722 0180 408A VSTRC v2,v2,v0,v4,b'0001',b'1000' E7E2 0001 2021 VLGV r14,v2,1,2 EC5E 000D 2076 CRJH r5,r14,@1L3 A74A FFF0 AHI r4,H'-16' A7FA 0010 AHI r15,H'16' EC4C 000E 007E CIJNH r4,H'0',@1L4 A7F4 FFE5 J @1L2 0700 NOPR 0 @1L3 DS 0H 20 ARCHitecture Option • The wonderful feature of the ARCH option is that no code changes are required by you • In all of the above examples, the compiler • figured out where it could exploit the option • and then did all the work 21 HGPR Option • Stands for High half of 64-bit General Purpose Register • Permitted to exploit 64-bit GPRs in 32-bit programs • Compiler can now make use of • The 64-bit version of the z/Architecture instructions • The High-Word Facility [with ARCH(7) or above] • Can be viewed as having an additional 16 GPRs • PRESERVE sub-option • Save/re-store in prolog/epilog the high halves of used GPRs • Only necessary if the caller is not known to be compiler- generated code • Default is NOHGPR(NOPRESERVE) • Metal C defaults to HGPR(PRESERVE) 22 FLOAT(AFP) Option • Additional Floating-Point (AFP) registers were added to ESA/390 models • AFP sub-option enable use of the full set (16) of FPRs • VOLATILE sub-option • FPR8 – FPR15 is considered volatile • i.e. compiler will not expect they’re preserved by any called program • No longer required for CICS TS V4.1 or newer • Default is AFP(NOVOLATILE) 23 OPTIMIZE Option • The OPT option controls how much, or even if at all, the compiler tries to optimize your code • A trade-off between compile-time vs. execution-time • NOOPT/OPT(0): • The compiler simply translates your code into machine code • Generated code could be large and slow • Good choice for: • Matching code generated with written source code • for the purpose of debugging a problem • Reducing compile time • Terrible choice if you care about run-time performance 24 OPTIMIZE Option (cont’d) • When optimizing, the compiler will improve, often vastly, the code it generates by, for example • Keeping intermediate values in registers • Moving code out of loops • Merging statements • Reordering instructions to improve the instruction pipeline • Inlining functions • Require more CPU and REGION during compilation 25 OPTIMIZE Option (cont’d) • OPT(2): • Start enabling the optimizer • A balance between compile speed and code quality • OPT(3): • Optimizer much more aggressive • Tips balance towards code quality over compile speed • C/C++ compiler will alter other options defaults: • ANSIALIAS, IGNERRNO, STRICT, etc • The C/C++ and PL/I compilers use the same optimizing backend • But there are differences in what the OPT sub-options does 26 Other C/C++ Options Related to OPT • HOT option • High-Order loop analysis and Transformations • More aggressive optimization on the loops • Requires OPT(2) or higher • IPA option • Inter-Procedural Analysis • Optimization decisions made based on the entire program • 3 sub-levels to control aggressiveness • Requires OPT(2) or higher • PDF sub-option • Profile Directed Feedback • Sample program execution to help direct optimization • Requires a training run with representative data 27 IPA Option [C/C++] (cont’d) IPA compile file1.c xlc file1.o libraries file2.c xlc file2.o xlc IPA(LINK) file3.c xlc file3.o binder executable 28 IPA PDF Sub-Option [C/C++] PDF1: xlc file.c file.o executable file2.c xlc file3.o file1.c xlc file.o with xlc instrumentation IPA compile PDF1 IPA link PDF1 Training run: executable typical input with profiling information instrumentation PDF2: file.o file3.o PDF optimized file.o xlc executable (w/o instrumentation) IPA link PDF2 29 ANSIALIAS Option [C/C++] • Optimizer presumes pointers can point only to objects of the same type • The simplified rule is that you cannot safely dereference a pointer that has been cast to a type that is not closely related to the type of what it points at • The ISO C and C++ standards define the closely related types • If this assumption is false, wrong code could be generated • The INFO(ALS) option might able to help you find potential violation of the ANSI type-based aliasing rule • OPT(3) defaults to ANSIALIAS • OPT(2) defaults is NOANSIALIAS • Has no effect to NOOPT/OPT(0) 30 IGNERRNO Option [C/C++] • Informs the compiler that the program is not using errno • Allows the compiler more freedom to explore optimization opportunities for certain library functions • For example: sqrt • Need to include the system header files to get the full benefit • OPT(3) defaults to IGNERRNO • NOOPT and OPT(2) defaults are NOIGNERRNO 31 LIBANSI Options [C/C++] • Indicates the name of an ANSI C library function are in fact ANSI C library functions and behave as described in the ANSI standard • The optimizer can generate better code based on existing behavior of a given function • E.g.