This is an old revision of the document!
Table of Contents
SPO600 2024 Summer Project
Goal
The goal of this project is to add a functioning proof-of-concept prototype of Automatic Function Multi-Versioning (AFMV) capability to the Gnu Compiler Collection (GCC) for AArch64 systems, building on previous work.
Project Stage 1: Preparation
1. Become familiar with the GCC build process. Build the current development version of GCC on AArch64 and x86 platforms. Get to know how long a full build takes, how to change the build options, and how to install a local (non-system, personal) copy of GCC.
2. Learn how to navigate the GCC codebase. Specifically, find out what code implements these aspects of the compiler and how to add to or change the code:
a. Find the code that controls the compilation passes, and how passes can be added.
b. Find the code that controls the argument parsing. Add a dummy argument and experiment with messages for the user that describe how and when that argument can be used.
c. Find out where argument information is stored and how it can be accessed in code.
d. Find out how dumps are produced during the compilation passes (in particular, during the tree passes). Become familiar with producing and reviewing these dumps. Create a dummy pass that produces a useful diagnostic dump.
Submitting your Project Stage 1
Blog your 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.
- 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.
- 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. Identify the types of tasks that are most attractive to you (and why) - some people love writing documentation, others like to perform testing, and others prefer to write and debug code (and have preferences about what type of code they like to work with).
- 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.
Resources
-
- See especially:
-
- Take particular note of the section on Contributing to GCC.
- Installing GCC, the GCC project's guide to compiling and installing the GCC compiler from source code
-
-
- Note that GCC is mirrored onto GitHub, but the main activity is conducted in the GCC git repository documented in the link above. The GitHub mirror is provided for the convenience of GitHub users, but the GitHub workflow (including approaches such as forking and pull requests) is not used by the GCC project; instead, they discuss and review patches through an email-based workflow.
Due Date
May 31June 6 for Stage 1
Project Stage 2: Implementation
Goal
We are attempting to add support for AFMV for aarch64 to GCC.
- No other architectures or compilers are in-scope for this project.
- This is a proof-of-concept implementation.
Tasks
| # | Name | Description | Notes | Lead |
|---|---|---|---|---|
| 1 | Command-line Parsing | Parse the GCC command line to pick up AFMV options, process the version list to validate the architectural feature specification | .opt file writing | |
| 2 | arch= Arguments | The current GCC AArch64 FMV capability accepts versions that are identified by feature flags (such as “sve2”) but does not accept “arch=” arguments such as “arch=armv9-a” (those type of arguments are accepted by the x86 FMV implementation). Add this functionality. | ||
| 3 | Apply FMV cloning to functions automatically | When the appropriate command-line options are provided, the compiler should automatically clone all functions, as if the target_clone attribute was specified. | ||
| 4 | Produce an error message if AFMV and FMV are used together | Produce an error if the compiler is invoked with AFMV command-line options and there are FMV attributes specified in the code. | ||
| 5 | Prune Cloned Functions (1) | Remove any AFMV-created clone functions that do not provide any significant benefit or differentiation - Task 1: determine which function(s) to prune. | ||
| 6 | Prune Cloned Functions (2) | Remove any AFMV-created clone functions that do not provide any significant benefit or differentiation - Perform function pruning. | ||
| 7 | Diagnostic Output | Provide diagnostic output (when activated by -fdump-…-… command-line options). | ||
| 8 | Git Wrangler | Mangage the repository. | This task includes rebasing as upstream changes and managing code reviews. | |
| 9 | Update Documentation 1 | Update the existing GCC IFUNC and FMV documentation (all archs) | Technical writing. | |
| 10 | Create AFMV Documentation | Create documentation for the AFMV feature. | Technical writing. | |
| 11 | Create Tests | Create a suite of tests for the AFMV capability. (This is in addition to individual tests that the various task owners will prepare). | Requires understanding the existing test framework and writing tests. | |
| 12 | Test AFMV Implementation | Use the existing test suite(s) to verify that the aarch64 changes are not introducing regressions on aarch64 or x86-64. | Requires understanding and using the existing test framework; may involve scripting. |
What's Needed
Make as much progress on the task identified above as possible!
Previous Work
The previous semester made some preliminary progress on some of these tasks. You can find the blog posts and the GitHub commits via these resources:
Submitting your Project Stage 2
Blog your 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.
- 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.
- 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. Identify the types of tasks that are most attractive to you (and why) - some people love writing documentation, others like to perform testing, and others prefer to write and debug code (and have preferences about what type of code they like to work with).
- 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.
Due Date
- June 14 for Stage 2