Before starting this project, please perform Lab 4.

Create a pass for the current development version of the GCC compiler which:

1. Iterates through the code being compiled;
2. Prints the name of every function being compiled;
3. Prints a count of the number of basic blocks in each function; and
4. 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.

• Creating a GCC Pass.
• 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 (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.

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.

• 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.