SPRUIV4C May   2020  – December 2023

 

  1.   1
  2.   Read This First
    1.     About This Manual
    2.     Related Documentation
    3.     Trademarks
  3. 2Introduction
    1. 2.1 C7000 Digital Signal Processor CPU Architecture Overview
    2. 2.2 C7000 Split Datapath and Functional Units
  4. 3C7000 C/C++ Compiler Options
    1. 3.1 Overview
    2. 3.2 Selecting Compiler Options for Performance
    3. 3.3 Understanding Compiler Optimization
      1. 3.3.1 Software Pipelining
      2. 3.3.2 Vectorization and Vector Predication
      3. 3.3.3 Automatic Use of Streaming Engine and Streaming Address Generator
      4. 3.3.4 Loop Collapsing and Loop Coalescing
      5. 3.3.5 Automatic Inlining
      6. 3.3.6 If Conversion
  5. 4Basic Code Optimization
    1. 4.1  Signed Types for Iteration Counters and Limits
    2. 4.2  Floating-Point Division
    3. 4.3  Loop-Carried Dependencies and the Restrict Keyword
      1. 4.3.1 Loop-Carried Dependencies
      2. 4.3.2 The Restrict Keyword
      3. 4.3.3 Run-Time Alias Disambiguation
    4. 4.4  Function Calls and Inlining
    5. 4.5  MUST_ITERATE and PROB_ITERATE Pragmas and Attributes
    6. 4.6  If Statements and Nested If Statements
    7. 4.7  Intrinsics
    8. 4.8  Vector Types
    9. 4.9  C++ Features to Use and Avoid
    10. 4.10 Streaming Engine
    11. 4.11 Streaming Address Generator
    12. 4.12 Optimized Libraries
    13. 4.13 Memory Optimizations
  6. 5Understanding the Assembly Comment Blocks
    1. 5.1 Software Pipelining Processing Stages
    2. 5.2 Software Pipeline Information Comment Block
      1. 5.2.1 Loop and Iteration Count Information
      2. 5.2.2 Dependency and Resource Bounds
      3. 5.2.3 Initiation Interval (ii) and Iterations
      4. 5.2.4 Constant Extensions
      5. 5.2.5 Resources Used and Register Tables
      6. 5.2.6 Stage Collapsing
      7. 5.2.7 Memory Bank Conflicts
      8. 5.2.8 Loop Duration Formula
    3. 5.3 Single Scheduled Iteration Comment Block
    4. 5.4 Identifying Pipeline Failures and Performance Issues
      1. 5.4.1 Issues that Prevent a Loop from Being Software Pipelined
      2. 5.4.2 Software Pipeline Failure Messages
      3. 5.4.3 Performance Issues
  7. 6Revision History

4.5 MUST_ITERATE and PROB_ITERATE Pragmas and Attributes

The compiler can often generate faster code when the compiler knows how many times a loop will execute. Adding this information via the MUST_ITERATE and PROB_ITERATE pragmas and the TI_must_iterate and TI_prob_iterate C++ attributes can help the compiler:

  • Determine if it is profitable to vectorize a loop
  • Determine if it is profitable to perform certain loop optimizations and loop nest optimizations
  • Determine if a redundant loop is needed (see Redundant Loops, below)

Before vectorizing a loop, the compiler tries to determine if the change will improve performance. It is helpful if the compiler has information about the iteration counts of the loop so the compiler can make better predictions about the profitability of vectorization. In the same way, the compiler also tries to determine if certain loop optimizations and loop-nest optimizations will be profitable and so information about the iterations counts of the loops can be helpful to the compiler.

Note: Do not provide incorrect information about the iteration count in the MUST_ITERATE pragma or TI_must_iterate C++ attribute. If incorrect information is specified in this pragma/attribute, the compiler may create code that produces unexpected and incorrect behavior.

Redundant Loops: In some cases, if the compiler does not know how many times a loop will execute, the compiler generates two different versions of the loop. Software pipelined loops often must execute a certain minimum number of iterations to be legal to execute. If the iteration count of the loop is less than this minimum safe iteration count, the compiler generates a run-time iteration count check and branches to either the software pipelined version of the loop, or a duplicate loop. That is, the compiler generates a "regular" version of the loop (that executes much more slowly).

The minimum safe iteration count depends on how many iterations were scheduled in parallel and how effectively the compiler was able to perform an optimization called stage collapsing. See Section 5.2.6 for more information.

The Software Pipeline Information in the comment block in the assembly file specifies the minimum safe iteration count (iteration count) of the loop and states whether the compiler has generated a duplicate loop.

Because the compiler must sometimes generate a redundant loop and the control code necessary to choose between the two loops, it is helpful to tell the compiler the minimum iteration count of the loop with a MUST_ITERATE pragma when it is known, as the redundant loop may not be necessary. This can improve performance, especially when the loop is enclosed within an outer loop and if the compiler can then perform loop collapsing or other loop optimizations with the outer and inner loops.

The following example shows redundant loop generation information in the Software Pipeline Information section of the assembly comment block.

;*      Redundant loop generated
;*      Collapsed epilog stages       : 5
;*      Prolog not removed
;*      Collapsed prolog stages       : 0