1 / 25

Validating Code Improving Transformations in Embedded Systems

This paper introduces VISTA, a system for tuning applications by orchestrating compiler optimizations and hand-crafted code improvements, with undo/redo features. It validates the importance of compiler optimizations for high-risk embedded systems, providing insights from related works and system overview. The paper discusses modeling ISA semantics, transforming code regions, calculating effects, merging regions, and extending transformation scopes. It also covers merging potential aliases, conditional effects, loop effects, and dataflow analysis, aiming to enhance code quality in embedded applications.

mort
Download Presentation

Validating Code Improving Transformations in Embedded Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Validation of Code-Improving Transformations for Embedded Systems Robert van EngelenDavid WhalleyXin Yuan

  2. Introduction • Validation of: • Compiler optimizations • Hand-crafted code optimizations • VISTA: VPO Interactive System for Tuning Applications • View of the program representation • Allows orchestrating compiler optimizations applied to application code • Supports the editing hand-crafted code optimizations • Undo/redo facilities SAC03

  3. VISTA SAC03

  4. Motivation • Embedded system software developers often write code in assembly to meet hardware/software design constraints • Assembly optimized code is error-prone without tool support • Validation of compiler optimizations is important for high-risk systems SAC03

  5. Related Work • Horwitz: “Identifying the Semantic and Textual Differences between Two Versions of a Program” [PLDI90] • Limited number of high-level program constructs • Rinard & Marinov: “Credible Compilation with Pointers” [FLoC99] • Compiler writer must define invariants (formulas) for each transformation SAC03

  6. Related Work (cont’d) • Necula: “Translation Validation for an Optimizing Compiler” [PLDI00] • Transformations cannot change branch structure • Program slicing • From a subset of program behavior reduce the program to a minimum form that produces the behavior • Proving type and memory safeness • Complementary to our approach SAC03

  7. CFG System Overview C source code Determine transformed region VPO compiler or manual optimizations Get semantic effects at exit points Object code Compare normalized effects Ctadel algebraic simplifier SAC03

  8. Register Transfer Lists • RTLs are memory and register assignments • r[8]=0; • M[r[2]+.c]=r[8]; • PC=IC<0,L14; • Supports any ISA, e.g. predicated ILP forms • M[r[2]]=0; r[2]=r[2]+4; • M[r[2]]=IC<0,0; M[r[2]]=IC>=0,1; • Translation between assembly and RTL form is easy and can be automated SAC03

  9. Modeling ISA Semantics withRTL Effects • RTL defines the semantics of an ISA using memory/register effects • JMP Label in RTL: PC=Label; • LD r0,sp+8 in RTL: r[0]=M[r[14]+8]; • SUB r0,r1 in RTL: IC=r[0]?r[1]; r[0]=r[0]-r[1]; SAC03

  10. entry entry Validation of Code-Improving Transformations optimize exit exit effects effects exit exit effects effects exit exit effects effects SAC03

  11. Example Transformation IC=r[8]?0; PC=IC<0,L14; r[8]=r[9]; M[r[14]+.c]=r[8]; PC=L15; r[8]=r[9]; r[8]=-r[8]; M[r[14]+.c]=r[8]; Register allocation: replace M[r[14]+.c] with r[10] r[8]=M[r[14]+.c]; Dataflow analysis: M[r[14]+.c] is dead SAC03

  12. Calculating the Extent of a Region After a Transformation region IC=r[8]?0; PC=IC<0,L14; r[8]=r[9]; r[10]=r[8]; PC=L15; r[8]=r[9]; r[8]=-r[8]; r[10]=r[8]; Register allocation: replace M[r[14]+.c] with r[10] r[8]=r[10]; r[10]: Dataflow analysis: r[10] is dead SAC03

  13. Merging the Effects of a Region region IC=r[8]?0; PC=IC<0,L14; effects r[8]=r[9]; r[10]=r[8]; PC=L15; r[8]=r[9]; r[8]=-r[8]; r[10]=r[8]; r[8]=r[9]; r[10]=r[9]; r[8]=-r[9]; r[10]=-r[9]; Register allocation: replace M[r[14]+.c] with r[10] r[8]=r[10]; r[10]: Dataflow analysis: r[10] is dead { -r[9] if IC<0 r[8]= r[9] if IC>=0 SAC03

  14. Merging the Effects Within a Single Block region effects Merging (Before Transformation) Merging (After Transformation) r[16]=0; r[17]=HI[_s]; r[19]=r[17]+LO[_s]; r[17]: r[17]=r[16]+r[19]; r[16]: r[16]=0; r[16]: r[17]=HI[_s]; r[19]=r[17]+LO[_s]; r[17]: r[17]=r[19]; r[16]=0; r[17]=HI[_s]; r[19]=r[17]+LO[_s]; r[17]: r[17]=r[16]+r[19]; r[16]: r[17]=HI[_s]; r[19]=r[17]+LO[_s]; r[17]: r[17]=r[19]; r[16]=0; r[19]=HI[_s]+LO[_s]; r[17]=r[16]+r[19]; r[16]: r[19]=HI[_s]+LO[_s]; r[17]=r[19]; r[17]=HI[_s]+LO[_s]; r[19]=HI[_s]+LO[_s]; SAC03

  15. Extending the Scope of a Region region effects Before Transformation After Transformation r[16]=0; r[17]=HI[_s]; r[19]=r[17]+LO[_s]; r[17]: r[17]=r[16]+r[19];r[16]: r[16]=0; r[16]: r[17]=HI[_s]; r[19]=r[17]+LO[_s]; r[17]: r[17]=r[19]; r[17]=r[16]+r[19]; r[17]=HI[_s]+LO[_s]; r[19]=HI[_s]+LO[_s]; r[17]=r[19]; r[17]=HI[_s]+LO[_s]; r[19]=HI[_s]+LO[_s]; Not equivalent Equivalent SAC03

  16. Merging Potential Set/Use Alias region effects M[r[2]] and M[r[3]] are potential aliases M[r[2]]=r[4]; r[5]=M[r[3]]; { r[4] if r[2]==r[3] M[r[2]]=r[4]; r[5]= M[r[3]] if r[2]!=r[3] SAC03

  17. Merging Potential Set/Set Alias region effects M[r[2]] and M[r[3]] are potential aliases M[r[2]]=r[4]; M[r[3]]=r[5]; { r[5] if r[2]==r[3] M[r[3]]=r[5]; M[r[2]]= r[4] if r[2]!=r[3] SAC03

  18. Merging Conditional Effects B1 M[r[14]+.v]=r[8]; IC=r[8]?0; PC=IC>=0,B3; M[r[14]+.v]=(r[8] if r[8]>=0); M[r[14]+.v]=(r[8] if r[8]<0); B2 r[9]=-r[8]; M[r[14]+.v]=r[9]; r[9]: r[9] is dead M[r[14]+.v]=(-r[8] if r[8]<0); { join r[8] if r[8]>=0 M[r[14]+.v]= -r[8] if r[8]<0 B3 r[8]=M[r[14]+.v]; .v: .v is dead { r[8] if r[8]>=0 r[8]= -r[8] if r[8]<0 SAC03

  19. Loop Effects B1 M[r[14]]=0; r[14]=r[14]+4; IC=r[8]?0; r[8]=r[8]-1; PC=IC>=0,B1; M[r[14]..r[14]+4*i]=0; r[8]=r[8]-i; M[y(B1,w+4,r[14]) until y(B1,w-1,r[8])<0]=0; r[8]=y(B2,w-1,r[8]) until y(B1,w-1,r[8])<0; SAC03

  20. { 0+r[8] if r[8]==0 r[8]= r[8] if r[8]>0 and r[8]!=0 -r[8] if r[8]<0 and r[8]!=0 { r[8] if r[8]>=0 r[8]= -r[8] if r[8]<0 Normalization of Effects Get semantic effects at exit points Ctadel algebraic simplifier Fixed set of rewrite rules DNF Logic+guards Arithmetic Normalized effects at exit points SAC03

  21. = if if M[r[14].v] = if >=0 <0 = - r[8] Normalization of Effects with DAGs M[r[14]]+.v]=r[8]; IC=r[8]?0; PC=IC>=0,B3 M[r[14]+.v]=(r[8] if r[8]>=0); M[r[14]+.v]=(r[8] if r[8]<0); r[9]=-r[8]; M[r[14]+.v]=r[9]; r[9]: M[r[14]+.v]=(-r[8] if r[8]<0); SAC03

  22. Benchmarks SAC03

  23. Benchmarks SAC03

  24. Benchmarks SAC03

  25. Conclusions • Validation of both compiler and hand-specified optimizations • Keeps memory requirement low with DAG representation • Overhead is reasonable to justify assurance SAC03

More Related