PROJECT STAGE3

 Introduction:

For Stage III, my goal is to further validate and demonstrate that my project can accurately process multiple cloned functions in a single program and make individual PRUNE/NOPRUNE recommendations for each one. In fact, my project has already supported this functionality since Stage II. To identify cloned functions, I extract the base function name from fun->decl, then iterate over all functions in the program using FOR_EACH_FUNCTION(node) while ensuring each has a valid name. I check if a function’s name starts with the base name and includes a dot (.) afterward, which typically signifies a clone. I also skip any functions containing .resolver in their name. Functions that meet these criteria are printed as cloned functions. This approach allows the detection of multiple clones, assuming they follow GCC’s naming conventions. To enable this analysis, DUMP_ALL must be set to 1 to activate all GCC dumps. For this stage, I will create test cases with at least two cloned functions per program and verify PRUNE/NOPRUNE decisions on both x86_64 and aarch64.


Create one test case that contains two cloned functions

In order to contain a minimum of two cloned functions,I added a new clone of the scale_samples function, named scale_samples_v2, in the clone-test-core.c file. Both functions are identical in operation, and I applied the CLONE_ATTRIBUTE macro to them. In the main function, I called both scale_samples and scale_samples_v2 with the same input and output buffers, enabling the test binary to detect both clones. This update supports testing the compiler's clone detection and pruning capabilities without modifying the Makefile.

Updated clone-test-core.c:Click here



Output:

Problem at this point:
The GIMPLE dump was showing strange output like '8' and '10' instead of the actual function logic. So, I decided to switch to -O0 and added -fno-inline to force the compiler to keep both functions intact. This allowed me to test whether my customized pass can find all clone functions with the same code and operand types.

Updated makefile:Click here
After running make clean followed by make, the output now correctly shows the expected GIMPLE codes instead of the strange 8 10 values:

Output:


Problem at this point:
When I disable all optimizations with -O0 and add those specific flags, I am essentially preventing GCC from making any meaningful transformations to the code, which results in identical GIMPLE representations even for functions that should be different in the "noprune" case.However, this also confirms that my function is correctly identifying all cloned functions that have identical GIMPLE code and operand types.


Problem fixed:
I wrote my own test case, and it works.
Updated Test Case:click here

For noprune result:

For prune result:


I have created a GitHub folder containing all the necessary and changed files to test my function,and my function works correctly on both architectures (x86_64 and aarch64)  Github Repo: https://github.com/ZiyangWangGit/SPO-PROJECT/tree/main/Stage3Final

Reflection:

In this stage, I focused on ensuring that my program could properly handle PRUNE/NOPRUNE decisions for cloned functions. I created test cases with cloned functions to test how well the program could detect and process them. I faced a challenge with compiler optimizations, which caused strange outputs in the GIMPLE dump. To fix this, I turned off optimizations and added flags to stop the compiler from changing the code. This allowed me to check if the program could correctly detect cloned functions. After making these changes, I confirmed that the function detection worked well, even with optimizations turned off. The PRUNE/NOPRUNE decisions were also accurate in my tests. The GitHub repository contains all the necessary files to test my approach. This part of the project showed me how important it is to account for compiler optimizations when testing functions and how to deal with issues that arise during testing. 


Comments

Post a Comment

Popular posts from this blog

PROJECT STAGE2

Image
Introduction: In this task, I am required to create a pass for the GCC compiler that analyzes cloned functions in a program and determines whether or not they should be pruned. The goal is to identify cloned functions and compare them to see if they are "substantially the same" or different. I will find which functions are cloned and then analyze the differences between the two versions of the function. If the functions are identical except for things like variable names or labels, I will indicate that the function can be pruned. If they are different, I will indicate that the function should not be pruned. The functions are cloned using the FMV (Function Multi-Versioning) mechanism, which automatically handles function versioning. My pass must be positioned late in the compilation process, after optimizations are complete. To compare the cloned functions, I can either examine each statement or use a hash/signature to check if they are the same. Comparing Cloned Function Vers...
Read more

PROJECT STAGE1

Image
Project Stage 1 Overview In this project, we will update the compiler to add automatic features, allowing us to create one binary that works on more platforms. In the first stage, we will improve the compiler by adding extra optimization or transformation steps. This includes making a basic GCC pass that goes through the compiled code, prints each function's name, counts how many basic blocks are in each function, and shows the total number of GIMPLE statements in each function.  Step 1:Environment  Setup We will use three separate directories to manage our GCC setup and the modifications made in lab4 : Directories contain: git/gcc Directory – This is the source code directory where the GCC source files are stored. gcc-build-001 Directory – This is the build directory where the compilation process takes place. gcc-test-001 Directory – This is the installation directory where the final GCC binaries and related files are placed after a successful build. Step 2:  Understandi...
Read more

LAB 4

Image
Building GCC process: Step 1: Create a Directory for the GCC Source Code: Step 2: Clone the GCC Repository into the Source Directory:  Step 3: Create a Separate Build Directory Note: Building GCC directly in its source code directory is not recommended. Doing so can mix original source files with new files created during the build process, making it hard to manage the code. This can also cause problems with version control systems, which track changes in the code. To avoid these issues, it's better to create a separate directory for building GCC. This keeps the original source code clean and makes it easier to manage different build versions. For example, you can create a directory named gcc-build next to your GCC source code directory and perform the build process there. Step 4: Configure the Build Note: --prefix option specifies the installation directory for GCC after the build process. In this case, GCC will be installed in ~/gcc-test-001. gcc-build-001 Directory: Purpose: This...
Read more