Hand-Tuning Loops and Control Code on the TMS320C6000

Hand-Tuning Loops and Control Code on the TMS320C6000

Application Report SPRA666 – August 2006 Hand-Tuning Loops and Control Code on the TMS320C6000 Elana Granston Software Development Organization ABSTRACT The TMS320C6000 compiler automatically performs a great deal of performance-related tuning. This compiler-driven optimization usually suffices. For the occasional cases where additional CPU performance is needed, this application report presents strategies and examples for improving performance of C/C++ applications. Memory-related performance improvements (such as background DMA transfers or cache usage) are outside the scope of this report. The techniques apply to all members of the C6000 architecture family. The target audience is intermediate to advanced application developers. Familiarity with the C6000 architecture and experience developing code for this architecture is assumed. Contents 1 Introduction .....................................................................................................................................3 2 Overview of the TMS320C6000 ......................................................................................................3 2.1 TMS320C6000 Architecture ..........................................................................................3 2.2 TMS320C6000 Compiler ...............................................................................................5 3 General Performance Tuning Strategy..........................................................................................6 3.1 Selecting the Right Compiler Options............................................................................6 3.2 Basic Performance Tuning Tips.....................................................................................9 3.3 Exploiting Optimizer Comments (-s)............................................................................10 4 Tuning Software-Pipelined Loops ...............................................................................................11 4.1 Using restrict qualifiers, MUST_ITERATE pragmas, and _nasserts().........................12 4.1.1 Establishing a Baseline ...............................................................................................12 4.1.2 Eliminating Loop-Carried Dependencies .....................................................................14 4.1.3 Balancing Resources...................................................................................................16 4.1.4 Exploiting Wide Loads and Stores (SIMD) ..................................................................21 4.1.5 Rebalancing Resources ..............................................................................................22 4.1.6 Using the Compiler Consultant....................................................................................24 4.2 Tuning Interruptible Applications .................................................................................24 4.3 Handling Nested Loops ...............................................................................................26 4.4 Using Intrinsics to Tune Software-Pipelined Loops .....................................................27 4.4.1 Casting Between Types...............................................................................................27 4.4.2 Example Using Intrinsics .............................................................................................28 5 Optimizing Control Code..............................................................................................................36 5.1 Restrict Qualifying Pointers Embedded in Structures..................................................36 5.1.1 Basic Rules..................................................................................................................37 5.1.2 Identifying Cases When Copies of Pointers are Needed.............................................38 5.2 Optimizing “If” Statements ...........................................................................................42 1 SPRA666 5.2.1 If-Conversion ...............................................................................................................42 5.2.2 “If” Statement Reduction When No “Else” Block Exists ...............................................43 5.2.3 “If” Statement Elimination ............................................................................................44 5.2.4 “If” Statement Elimination By Use of Intrinsics.............................................................44 5.2.5 “If” Statement Reduction Via Common Code Consolidation........................................45 5.2.6 Eliminating Nested “If” Statements ..............................................................................45 5.2.7 Optimizing Conditional Expressions ............................................................................46 5.3 Handling Function Calls...............................................................................................47 5.4 Improving Performance of Large Control Code Loops ................................................48 5.4.1 Using Scalar Expansion to Split Loops........................................................................48 5.4.2 Optimizing Sparse Loops.............................................................................................49 6 Summary........................................................................................................................................52 7 References.....................................................................................................................................52 8 Acknowledgements.......................................................................................................................53 Figures Figure 1. Compiler Phases..........................................................................................................5 Figure 2. Software Pipelining ...................................................................................................12 Figure 3. Loop-Carried Dependency Cycles ...........................................................................15 Figure 4. Loop Unrolling ...........................................................................................................18 2 Hand-Tuning Loops and Control Code on the TMS320C6000 SPRA666 1 Introduction This application report provides techniques for hand-tuning loops and control code in C/C++ applications for the TMS320C6000 architecture. The remainder of this document is structured as follows: • Section 2 introduces the architectural features of the C6000 family of processors. These are necessary for understanding the tuning techniques presented later in this document. This section also presents an overview of the C6000 compiler. • Section 3 outlines a general performance tuning strategy and assists with the selection of compiler options used for code optimization. • Section 4 teaches how to optimize software-pipelined loops. • Section 5 focuses on control code optimization. • Section 6 concludes the document. • Section 7 provides links to related documents. Unless otherwise specified, examples in this application report use C6000 compiler version 5.1.3 (CCStudio version 3.1) and target the C64x. 2 Overview of the TMS320C6000 2.1 TMS320C6000 Architecture The C6000 architecture is an eight-way enhanced VLIW architecture. The C64x, C64x+, C67x+ contain 64 registers. The C62x and C67x devices contain 32 registers. The architecture is partitioned into two nearly symmetric halves (A-side and B-side) with limited connectivity between the two. All of these registers can be used for either data or addressing; there are no dedicated address registers. Each side contains half the registers and four functional units, noted by the types of instructions that execute on them: • M unit. Multiplication • D unit. Loads and stores • S unit. Shifts, branches and compares • L unit. Logical and arithmetic operations Each side contains two other resources that are important to consider when scheduling code: • X cross-path. Path between functional units and opposite-side register file • T address path. Path to memory Some operations can be done on more than one functional unit. For example, add instructions can execute on the L, S, or D units. Several other operations can be done on either the L or S units. Hand-Tuning Loops and Control Code on the TMS320C6000 3 SPRA666 Normally, each load and store uses one D unit and one T address path. The register containing the address must be on the same side as the D unit. The data register(s) must be on the same side as the T address path. All processor variants support byte/half-word/word (that is, 8-, 16-, and 32-bit) loads and stores. The C67x, C64x and C64x+ support aligned double-word (64-bit) loads. The C64x and C64x+ support aligned double-word stores. The C64x and C64x+ also allow non-aligned word-wide and non-aligned double-word wide memory-access instructions; these non-aligned loads and stores require the use of both T address paths.1 Most instructions can be predicated with a condition operator (that is, whether the instruction is executed depends on the value of another register). Many allow one register source operand to come from the opposite register file. When an instruction takes one of its register operands from the opposite side, it uses the X cross-path bus. There is one X cross path resource for each side: 1X = B-side register to an A-side unit, 2X=A-side register to a B-side unit. The T address

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    54 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us