starcoredsp compiler usability, tips and tricks...starcore dsp compiler usability, tips and tricks...

TMFreescale, the Freescale logo, AltiVec, C-5, CodeTEST, CodeWarrior, ColdFire, C-Ware, mobileGT, PowerQUICC, StarCore, and Symphony are trademarks of Freescale Semiconductor, Inc., Reg. U.S. Pat. & Tm. Off. BeeKit, BeeStack, CoreNet, the Energy Efficient Solutions logo, Flexis, MXC, Platform in a Package, Processor Expert, QorIQ, QUICC Engine, SMARTMOS, TurboLinkand VortiQa are trademarks of Freescale Semiconductor, Inc. All other product or service names are the property of their respective owners. © 2010 Freescale Semiconductor, Inc.

StarCore DSP Compiler Usability, Tips and TricksFTF-ENT-F0827

Robert McGowanSr. Product Manager, CodeWarrior

June, 2010


Introduction

►This session presents the compiler feedback information emitted by the StarCore DSP compiler that can assist users in optimizing their code.

►The tool helps reduce time to market in achieving optimized compiled code.

►It helps reduce time and effort in migrating code from other architectures to StarCore DSPs.

►It benefits users seeking to understand compiler internals, and how to write code better suitable to compiler optimizations.

2


Session Objectives

►After completing this session you will be able to:

• Understand choices that the compiler made during compilation

• Enable greater levels of optimization in your code

• Identify and correct missed opportunities for compiler optimization

• Decrease development time

• Ease migration of legacy code to Freescale solutions

• Write code in a compiler friendly manner

3


Agenda

►Motivations

►Overview of Compiler Complexity and Human Interaction

►Illustrative Uses of Compiler Feedback

►Guiding the Programmer to Writing Compiler Friendly Software

►Migrating Legacy Code to Freescale Solutions

►Features Set Overview

►Summary and Q&A

4


Motivations

►Together, Freescale and you, our customer, must outperform the competitor’s solution.

►Many times, projects begin with existing solutions, which are sometimes built on non-Freescale devices – the challenge is to not only migrate this code, but overcome hand optimization choices no longer applicable to the Freescale solution.

►Tools like compiler feedback lower the barrier to optimizing your application whether you started with existing code on another device, or if you are writing new code.

►lt is similar to problem in quantum mechanics, stuck in local minimum without additional effort!

5


Why Customers Care About Software Tools for StarCore

►Compiler is key in extracting the performance of the StarCore DSP cores.

►Programmers must understand:• Potential for optimizations• When optimizations are not performed• Why optimizations are not performed

►Yet, optimizing compilers are highly complicated software systems• Generated assembly often does not resemble source code.• Compiler may do 100s of transformations on the input code, so it is

often difficult to quickly see what was done by the compiler.

6


Why Customers Care About Software Tools for StarCore

►StarCore “compiler feedback” illustrates what was done by the compiler and hints at potential for code optimization to the end user

• Illustrates optimizations performed in assembly listing

• Hints on why potential optimizations could not be performed

• Hints on porting from competitor architectures

• Visually illustrates bottlenecks in assembly code performance

7


Agenda

►Motivations






►Summary and Q&A

8


Overview of Freescale’s SC3850 StarCore DSP Core

► Very Long Instruction Word (VLES) processor architecture• 7-instructions can be scheduled/issued in a single clock cycle• Compiler statically schedules instructions, no out-of-order hardware• Fully interlocked pipeline• Compiler is key in performance

► Multiple Register File Architecture• RREG register file for integer and address computation• DREG register file for data computation• Explicitly managed register file communication

► Robust DSP functionality• 7-ALU wide pipeline• Multiple powerful addressing modes• Multiple types of computation (saturating, non-saturating, integer)

9


Example Case: Software Pipelining of C-language Loops

►Consider the following loop scheduled on a machine which can issue one instruction per clock cycle:

►A naïve code schedule results in 7 cycles per iteration, due to dependencies between operations within a loop iteration.

►Software pipelining, a compile time optimization, can circumvent this by overlapping multiple iterations in parallel.

10

for (i=0 to big_number)A(i); // 3 clock cycles per

operationB(i); // dependence between

each // operation for iteration “i”.C(i); // no dependence between

// operations for iterations “i” // and “i+1”.end

A(1); // issues cycle 0B(1); // issues cycle 3C(1); // issues cycle 6A(2); // issues cycle 7B(2); // issues cycle 10C(2); // issues cycle 13A(3); // issues cycle 14B(3); // issues cycle 17C(3); // issues cycle 20

// 7 cycles per iteration



►Now let’s reconsider the same loop scheduled using software pipelining.

• Pipelining permits multiple iterations to be scheduled in parallel seen below.

►Software pipelining has overlapped the latency between operations, by exploiting the lack of dependency on operations across iterations!

• Each iteration has been scheduled in 3 cycles, versus 7 cycles in the previous example!

11

for (i=0 to big_number)A(i); // 3 clock cycles per

operationB(i); // dependence between

each // operation for iteration “i”.

C(i); // no dependence between // operations for iterations

“i” // and “i+1”.end

A(1); // issues cycle 0A(2); // issues cycle 1A(3); // issues cycle 2B(1); // issues cycle 3B(2); // issues cycle 4B(3); // issues cycle 5C(1); // issues cycle 6C(2); // issues cycle 7C(3); // issues cycle 8

// 3 cycles per iteration!



►Software pipelining is a complex code scheduling optimization• Out-of-order scheduling of instructions to maximize ILP

►Compiler may try many different schedules before choosing one• Results dependent on architecture resources• Results dependent on input source code shape

►Quality of transformations performed can be obfuscated in assembly• How well are processor resources utilized in code schedule?• What scheduling parameters did the compiler choose? Why?• Can original source code be changed to help the compiler? How?

►The following slides illustrate how StarCore compilers illustrate this information to the end user.

12


Agenda

►Motivations and Customer Perspective






►Summary and Q&A

13


Invoking Compiler Feedback

►To gain greater insight into the compiler’s choices, we want to invoke compiler feedback.

Add –compiler_feedback to the command line

►During compilation, the compiler will add comments to the assembly output.

►These comments before functions, loops, and some basic blocks reflect information on the choices that the compiler made.

14


Example Case: Software Pipelining of C-language Loops (cont)

► Information in assembly listing• Line numbers and files• Optimizations performed• Iterations scheduled in parallel• Loop unrolling information• Dynamically pipelined• (highly abridged example)

► Information Reported:• All functions• All loops• Basic blocks, instructions,

registers• Vectorized instructions etc

15


Example Case: Software Pipelining of C-language Loops (cont)

► Basic Block Maps• Registers defined and used

(def/use) per cycle, or spilled to memory

• Registers live on entry to block (live-in), or live on exit from block (live-out)

• Mode of ALU use (scalar or SIMD).

► Visually explains the quality and density of the code schedule to the programmer

• Fast user feedback loop• Iteratively tune and recompile• Shorten optimization cycle!

16


Register Usage, Spill & Fill

X => define / use- => spill+ => reload

17

RegistersRREG DREG


Liveness

+ => define. => live

^ => live in/outX => use* => def+use

18

RegistersRREG DREG

Live out

Live in


Utilization

X => useX2 => SIMD. => Stall

19

AddressUnits

Data Units


Information is Key to Making Improvements

►Basic Block Maps• Address register file (R00-15) and Data

register file (D00-15) information• Registers defined and used (def/use)

per cycle, or spilled to memory• Registers live on entry to block (live-in),

or live on exit from block (live-out)• Mode of ALU use (scalar or SIMD).

►Visually explains the quality and density of the code schedule to the programmer

• Fast user feedback loop• Iteratively tune and recompile• Shorten optimization cycle!

20


Agenda

►Motivations






►Summary and Q&A

21


What About Hidden Opportunities for Performance?

►Compiler can be sensitive to input source coding style, structure

►Improper coding style can impede a compilers ability to optimize• Memory alignment of data• Restrict qualifiers on keywords• Data types used• Legacy hand optimized code from other architectures

22

►The following slides illustrate when the compiler can not optimize for various reasons

• Illustrate problem to user• Teach user the solution


Learning From the Compiler When Writing New Code

►Compiler can not determine value of ‘k’!• Prevents knowing dependence dist.• Suboptimal software pipeline at best• No software pipeline at worst!• May generate multiple versions of loop,

increasing code size!

► Compiler will warn and guide user• Potential aliased pointer use• Failure to pipeline loop• Advise using inter-procedural analysis to

propagate value of “k”.• Advise using assert statements on

possible values of “k” to enable optimization

23


Agenda

►Motivations






►Summary and Q&A

24


Migrating Legacy Code to Freescale

►Software is often the customer’s intellectual property• Major investment in time and money

►Customer may have hand tuned code in prior products• Competitor’s DSP• Prior StarCore DSP architecture• General embedded devices

►Minimize the barrier to updating to the newer Freescale solutions• Help the user understand where changes should be made

25


Migrating Legacy Code to Freescale

►Legacy code example:• Hand tuned to different architecture

Loop was manually unrolled in an attempt to expose instruction level parallelism

• Tuned to highly parallel architecture• However, it

Exhausts resources of SC3850 core!Inefficient code generated on SC3850

► Compiler feedback alerts the user• Warns about too much loop unrolling• Warns about spill code inserted• Maps out critical basic block resources• Suggests rerolling be performed• Suggests tips on vectorizing the code

26


Agenda

►Motivations






►Summary and Q&A

27


Compiler Feedback Features: High Level Overview *► Loop Header Information

• Example: line number in the source files for loop entry/exit points.

► Software Pipelining Diagnostics• Example: A loop was software pipelined with N iterations in parallel,

and with X% ALU utilization.

► General Loop Optimization Diagnostics• Example: The Loop at line #100 in file my_file.c unrolled with a factor

of 4 iterations.

► Liveness Analysis Information• Example: The Basic block in loop #100 has registers R0-R1 live-in to

the block, registers R2-R3 live-out of block, R0 clobbered within block.

28

* List is significantly abridged


Compiler Feedback Features: High Level Overview *

►Register File Usage Statistics• Example: For each clock cycle in a instruction schedule, a lists of the

registers defined, used, or destroyed is given.

►ALU Usage Statistics• Example: For each clock cycle, which of the seven ALUs in the pipeline

are performing a computation or idle.

► Alias Information Diagnostics• Example: for-loop at line #100 in my_file:c, pointers may alias each

other. Compiler has failed to optimize loop, please consider using restrict keyword.

29



Compiler Feedback Features: High Level Overview *

►Hardware Loop Diagnostics• Example: for-loop at line #100 has been replaced with a zero overhead

hardware loop.

►VLES Scheduling Statistics• Example: Percent instruction utilization per VLES is given for all

instruction bundles in a given function and loop.

►Compile Time Optimization Failures and Suggestions• Example: Failed to software pipeline loop at line #100 due to excessive

register pressure in loop. Consider manually re-rolling loop iterations.

30



Session Summary

►Freescale DSPs come with a robust set of software tools allowing programmers to develop rapidly and easily.

►Compiler Feedback feature annotates assembly code with information about quality of instruction scheduling and compileroptimizations, as well as warnings to the programmer.

►By guiding the user on the quality of optimizations performed on the code, users can achieve faster development cycles when performance is critical to the application.

31

starcoredsp compiler usability, tips and tricks...starcore dsp compiler usability, tips and tricks...

Documents