Differences

This shows you the differences between two versions of the page.

--- spo600:2025_winter_project [2025/03/14 10:21] – chris
+++ spo600:2025_winter_project [2025/04/15 06:41] (current) – [What was planned for Stage III] chris
@@ Line 5: / Line 5: @@
 Before starting this project, please perform [[GCC Build Lab|Lab 4]].
-===== Project Stage 1: Create a Basic GCC Pass =====
+===== Project Stage I: Create a Basic GCC Pass =====
 Create a pass for the current development version of the GCC compiler which:
@@ Line 39: / Line 39: @@
 You can do your development work on either architecture, but remember to test your work on both architectures.
-==== Submitting your Project Stage 1 ====
+==== Submitting your Project Stage I ====
 Blog about your process and results:
@@ Line 54: / Line 54: @@
   * This stage of the project is worth 15% of the course total.
-===== Project Stage 2: Clone-Pruning Analysis Pass =====
+===== Project Stage II: Clone-Pruning Analysis Pass =====
 Create a pass for the GCC compiler which analyzes the program being compiled and:
@@ Line 64: / Line 64: @@
   * Start with your code from Stage I
   * Add the logic to find the cloned function(s)
-  * Add the locic to compare the gimple representation of the funtion(s)
+  * Add the logic to compare the gimple representation of the funtion(s)
   * Add the code to output a decision on whether the functions should or should not be pruned
@@ Line 77: / Line 77: @@
 Two possible approaches to this problem are (1) to iterate through the statements in each function, comparing them statement-by-statement; or (2) generating some type of hash or signature that uniquely identifies the implementation of the function and which can be compared to the hash/signature of a clone to see if they are different. In either case, you need to accomodate the variation in variable, label, and basic block names.
-You must output one of these specific strings in your dump file, each on its own line, conditional on whether the cloned functions are the same (PRUNE) or different (NOPRUNE):
+You must output one of these specific strings in your dump file //per function//, each on its own line, conditional on whether the cloned functions are the same (PRUNE) or different (NOPRUNE):
   * ''PRUNE: //function//''
   * ''NOPRUNE: //function//''
@@ Line 92: / Line 92: @@
 Your code must be able to correctly output PRUNE or NOPRUNE messages for the test programs on each platform.
-==== Submitting your Project Stage 2 ====
+==== Submitting your Project Stage II ====
 Blog your results:
@@ Line 104: / Line 104: @@
 ==== Due Date ====
-  * Stage 2 is due with the third batch of blog posts on March 6, 2024.
+  * Stage II is due with the third batch of blog posts on April 6, 2025.
-  * This stage of the project is worth 15% of the course total.
+  * This stage of the project is worth 20% of the course total.
+===== Project Stage III: Tidy & Wrap =====
+==== What was planned for Stage III ====
+My original intention for Stage III was to provide a GCC codebase that included AFMV cloning -- that is to say, every function would be cloned, without having to add the ''target_clones'' attribute to each function -- that you could test against.
+Here's the background: there are at least two ways that AFMV cloning can be implemented...
+  * By changing the logic that applies function multiversioning to each function so that it will do so regardless of the attributes present on that function when AFMV is enabled. This can be performed by altering the ''expand_target_clones'' function in ''gcc/multiple_target.cc''.
+  * Alternatively, a pass could be added early in the processing that would automatically add the ''target_clone'' attribute information to each function declaration node in the tree structure.
+I attempted to use the first approach, incorporating some work started by a student in the summer of 2024. However, subsequent issues with this approach arose from the assumption built into the code code that information about the architectural variants should be available in the tree representation of the code (Gimple). This is not the case, leading to a segmentation fault (segfault) in the later portions of the AFMV processing, in the case where the compiler has determined that a function cannot be cloned due to a (pretty rare!) situation where there is a non-local ''goto'' statement. This exact situation occurs within the GCC code //itself//, which causes the normal bootstrap compilation to fail.
+I spent a considerable effort to rectify this issue but was not able to do so in time to incorporate AFMV cloning into the codebase for Stage III of this semester's project; my current perspective is that the second approach outlined above is probably the cleaner way to tackle this issue.
+Therefore, we're going to use Stage III to wrap up our project work with enhanced testing, //without// AFMV automatic cloning.
+==== Requirements for Stage III ====
+  * Extend the functionality of your code so that it can process multiple sets of cloned functions and make a PRUNE / NOPRUNE recommendation for each (your code may already do this). In other words, remove the assumption from Stage II that "There is only one cloned function in a program".
+  * Create one or more test cases that contain a minimum of two cloned functions per program. You can do this by extending the test cases that I provided for Stage II; or you can create your own test cases.
+  * Verify that your code works correctly on both architectures (x86_64 and aarch64), with multiple functions, in both the PRUNE and NOPRUNE scenarios.
+  * Ensure that you test a scenario where one (or more) functions have a PRUNE recommendation while one (or more) other functions have a NOPRUNE recommendation. This is probably most easily done by having one function that does a simple operation such as I/O or scalar arithmetic, and another function that processes an array or buffer of data in a way that is vectorizable.
+  * Clean up any remaining issues you have identified with your Stage II work.
+==== Submitting your Project Stage III ====
+Blog your results:
+  * Include detailed results for the items above. Be specific, detailed, and conclusive in your reporting, especially regarding your test cases and test results.
+  * Clearly identify the capabilities and limitations of your code, including the scope of coverage of your test cases.
+  * Enable __easy__ 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. **Your code __must__ be easily testable, and include the code and build instructions (e.g., ''Makefile'') for your test cases.**
+  * Add your final reflections on the experience.
+==== Due Date ====
+  * Stage III is due with the fourth batch of blog posts at 11:59 PM on April 17, 2025.
+  * This stage of the project is worth 25% of the course total.