====== SPO600 2025 Winter Project ======

==== Before Starting ====

Before starting this project, please perform [[GCC Build Lab|Lab 4]].

===== Project Stage 1: Create a Basic GCC Pass =====

Create a pass for the current development version of the GCC compiler which:
  - Iterates through the code being compiled;
  - Prints the name of every function being compiled;
  - Prints a count of the number of basic blocks in each function; and
  - Prints a count of the number of gimple statements in each function.

Your code must build on both of the [[SPO600 Servers]].

It is recommended that you proceed in steps:
  * Create a basic dummy pass with a diagnostic dump
  * Add logic to iterate through the code in the program being compiled
  * Incrementally add logic to count the basic blocks and gimple statements

It is recommended that you position your compiler pass __late__ in the compilation/optimization process.

==== Resources ====

  * [[Creating a GCC Pass]].
  * [[Building GCC]]

==== Recommendations for Building GCC ====

A reminder that the ''make'' utility will rebuild a codebase in as few steps as possible. It does this by comparing the timestamps of the dependencies (inputs) for each target (output) to determine which source (or other input files) have changed since the related targets were built, and then rebuilding only those targets.

This can effectively cut the build time for a complex project like GCC from hours to minutes. On my development system (a Ryzen 7735HS with 32 GB RAM), a null rebuild (no source changes - make is checking that everything is up-to-date) takes about 8.3 seconds, and a rebuild with edits to one pass source file take 23-30 seconds. On the [[SPO600 Servers]] the rebuild times are similar.

To take advantage of this capability, do an initial full build of GCC in a separate build directory as usual, then make whatever required edits to the source code in the source directory. Run ''make'' with appropriate options (including ''-j'' job values) in the build directory.

Remember to use [[Screen Tutorial|screen]] (or a similar program such as tmux) when building on remote systems in case your network connection gets interrupted, and it's a good idea to time every build (prepend ''time'' to your ''make'' command) and redirect both stdout and stderr to a log file: ''time make ... |& tee build.log'' if you also want to see the output on the terminal or ''time make ... &> build.log'' if you don't want to see the output.

You can do your development work on either architecture, but remember to test your work on both architectures.

==== Submitting your Project Stage 1 ====

Blog about your process and results:
  * Include detailed results for the items above. Be specific and conclusive in your reporting, and include detail such as build options and build time, specific files and directories identified as you learned to navigate the code, and the specific code used in your experimentation. 
  * Clearly identify the capabilities and limitations of your code.
  * Enable replication of your results. For example, you could provide links to specific content in a Git repository of your experiments. Avoid presenting code as screenshots whenever possible, because screenshots are not searchable, indexable, testable, nor accessible. **It must be possible to easily test your code.**
  * Add your reflections on the experience - what you learned, what you found interesting, what you found challenging, and what gaps you have identified in your knowledge and how you can address those gaps. 
  * I recommend that you blog about your work in multiple sections - blog as you go rather than waiting and writing one massive blog post at the end of each stage.
  * Assuming that the basic work is done well, extending your Stage 1 work with particularly well-formatted dump text or additional detail in the output could improve your mark.

==== Due Date ====

  * Stage 1 is due with the second batch of blog posts on March 9, 2025.
  * This stage of the project is worth 15% of the course total.