Personal tools

Difference between revisions of "SSR combined with FREP in LLVM/Clang (M/1-3S)"

From iis-projects

Jump to: navigation, search
(Redirected page to LLVM and DaCe for Snitch (1-2S))
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
[[Category:Digital]]
+
#Redirect [[LLVM and DaCe for Snitch (1-2S)]]
 +
 
 +
<!--[[Category:Digital]]
 
[[Category:High Performance SoCs]]
 
[[Category:High Performance SoCs]]
 
[[Category:Computer Architecture]]
 
[[Category:Computer Architecture]]
Line 8: Line 10:
 
[[Category:Tbenz]]
 
[[Category:Tbenz]]
 
[[Category:Zarubaf]]
 
[[Category:Zarubaf]]
[[Category:Fschuiki]]
+
[[Category:Fschuiki]]-->
[[Category:Reserved]]
+
[[Category:Outdated pitches]]
 
Currently leveraging the Xssr and Xfrep extensions of Snitch require manual assembly programming. This includes programming the SSR address generators, enabling SSR semantics of a region of code, discouraging the compiler from using the stream registers for regular code, and inserting FREP as appropriate. We believe that for simple cases a lot of this work can be done directly by the compiler, such that leveraging SSR/FREP does not require manual assembly, but “only” adherence to a specific “loop coding style”. In a very crude prototype, we have explored how the RISC-V LLVM backend could be extended to automatically detect loads/stores that are amenable for SSR replacement, and to actually insert the necessary code. Expanding a transformation pass like this to cover also FREP and more complex loops would be the target of this thesis. Besides trying to do all the magic automatically, there would also be ample benefit in coming up with a scheme of compiler intrinsics that give the programmer control over which SSRs are used and how FREP is executed as a first step. This could include things like address generation configuration, “popping” a value from a stream, and marking a set of float operations as a dedicated FREP loop.
 
Currently leveraging the Xssr and Xfrep extensions of Snitch require manual assembly programming. This includes programming the SSR address generators, enabling SSR semantics of a region of code, discouraging the compiler from using the stream registers for regular code, and inserting FREP as appropriate. We believe that for simple cases a lot of this work can be done directly by the compiler, such that leveraging SSR/FREP does not require manual assembly, but “only” adherence to a specific “loop coding style”. In a very crude prototype, we have explored how the RISC-V LLVM backend could be extended to automatically detect loads/stores that are amenable for SSR replacement, and to actually insert the necessary code. Expanding a transformation pass like this to cover also FREP and more complex loops would be the target of this thesis. Besides trying to do all the magic automatically, there would also be ample benefit in coming up with a scheme of compiler intrinsics that give the programmer control over which SSRs are used and how FREP is executed as a first step. This could include things like address generation configuration, “popping” a value from a stream, and marking a set of float operations as a dedicated FREP loop.
  
Line 26: Line 28:
  
 
===== Project Supervisors =====  
 
===== Project Supervisors =====  
 +
* [[:User:Sriedel | Samuel Riedel]]: [mailto:sriedel@iis.ee.ethz.ch sriedel@iis.ee.ethz.ch]
 +
* [[:User:Tbenz | Thomas Benz]]: [mailto:tbenz@iis.ee.ethz.ch tbenz@iis.ee.ethz.ch]
 +
* [[:User:Paulsc | Paul Scheffler]]: [mailto:paulsc@iis.ee.ethz.ch paulsc@iis.ee.ethz.ch]
 
* [[:User:Fschuiki | Fabian Schuiki]]: [mailto:fschuiki@iis.ee.ethz.ch fschuiki@iis.ee.ethz.ch]
 
* [[:User:Fschuiki | Fabian Schuiki]]: [mailto:fschuiki@iis.ee.ethz.ch fschuiki@iis.ee.ethz.ch]
 
* [[:User:Zarubaf | Florian Zaruba]]: [mailto:zarubaf@iis.ee.ethz.ch zarubaf@iis.ee.ethz.ch]
 
* [[:User:Zarubaf | Florian Zaruba]]: [mailto:zarubaf@iis.ee.ethz.ch zarubaf@iis.ee.ethz.ch]
* [[:User:Sriedel | Samuel Riedel]]: [mailto:sriedel@iis.ee.ethz.ch sriedel@iis.ee.ethz.ch]
 
 
Co-supervised by Prof. Torsten Hoefler's group
 
Co-supervised by Prof. Torsten Hoefler's group
 
* Alexandru Calotoiu  -- acalotoiu at inf.ethz.ch
 
* Alexandru Calotoiu  -- acalotoiu at inf.ethz.ch

Latest revision as of 19:06, 15 February 2021

Currently leveraging the Xssr and Xfrep extensions of Snitch require manual assembly programming. This includes programming the SSR address generators, enabling SSR semantics of a region of code, discouraging the compiler from using the stream registers for regular code, and inserting FREP as appropriate. We believe that for simple cases a lot of this work can be done directly by the compiler, such that leveraging SSR/FREP does not require manual assembly, but “only” adherence to a specific “loop coding style”. In a very crude prototype, we have explored how the RISC-V LLVM backend could be extended to automatically detect loads/stores that are amenable for SSR replacement, and to actually insert the necessary code. Expanding a transformation pass like this to cover also FREP and more complex loops would be the target of this thesis. Besides trying to do all the magic automatically, there would also be ample benefit in coming up with a scheme of compiler intrinsics that give the programmer control over which SSRs are used and how FREP is executed as a first step. This could include things like address generation configuration, “popping” a value from a stream, and marking a set of float operations as a dedicated FREP loop.

Further reading
Requirements
  • C/C++, Python programming skills
  • Compiler design know-how
  • Interest in code generation
  • Interest in or experience with the LLVM/Clang codebase
  • Ability to endure soul-crunching hardware simulation environments

Composition: 50% Implementation, 30% Arhitecture, 20% Evaluation

Project Supervisors

Co-supervised by Prof. Torsten Hoefler's group

  • Alexandru Calotoiu -- acalotoiu at inf.ethz.ch