Supplemental: Project Stage 1 – GCC Pass Implementation

-

Introduction

In this blog post, I will demonstrate that my custom GCC pass functions correctly and outputs the required information. This supplements my original submission, incorporating the feedback received. The focus is on verifying the pass by producing a diagnostic dump file showing function names, basic block counts, and GIMPLE statement counts.

Challenges and Concerns

In my initial submission, I focused on building the pass but failed to demonstrate its functionality clearly. The pass was implemented, but I did not include a demonstration that the pass was outputting the necessary diagnostic information: function names, basic block counts, and GIMPLE statement counts. The feedback from the professor mentioned that the pass did not generate the expected output, specifically the required dump file or the output on stdout/stderr.

To resolve this, I revisited the code to ensure it was properly implemented and outputting the expected diagnostic information. The missing link seemed to be that the pass was not generating the necessary output files and didn't provide evidence that the pass was executed successfully. 

Overview: What is a Pass?

A pass in GCC is a stage in the compilation process that analyzes or transforms the source code. This allows the compiler to optimize code or, as in my case, gather information. My custom pass performs the following tasks:

  • Iterates through the code being compiled

  • Prints the name of each function

  • Counts the number of basic blocks per function

  • Counts the number of GIMPLE statements per function

Creating the Pass

I created a pass file pass_ayoung.cc within ~/gcc/gcc. Below is the final working code:

#include "config.h"
#include "system.h"
#include "coretypes.h"
#include "tree.h"
#include "tree-pass.h"
#include "cgraph.h"
#include "function.h"
#include "basic-block.h"
#include "gimple.h"
#include "gimple-iterator.h"
#include "cfg.h"

namespace{

const pass_data pass_data_ayoung = {
        GIMPLE_PASS,    /* type */
        "ayoung", /* name */
        OPTGROUP_NONE,  /* optinfo_flags */
        TV_NONE,        /* tv_id */
        PROP_cfg,	/* properties_required */
        0,              /* properties_provided */
        0,              /* properties_destroyed */
        0,              /* todo_flags_start */
        0,              /* todo_flags_finish */
};

// Pass class
class pass_ayoung : public gimple_opt_pass {
public:
       	// Constructor
        pass_ayoung(gcc::context* ctxt) : gimple_opt_pass(pass_data_ayoung, ctxt){};

        unsigned int execute(function* func) override{
                struct cgraph_node* node;
                int func_cnt = 0;

                // Iterate functions
                FOR_EACH_FUNCTION(node){
                        // Iterate basic blocks of the function
                        int bb_cnt = 0, gimple_stmt_cnt = 0;
                        basic_block bb;
                        FOR_EACH_BB_FN(bb, func){
                                bb_cnt++;

                                // Iterate GIMPLE statements in the basic block
                                for(gimple_stmt_iterator gsi = gsi_start_bb(bb); !gsi_end_p(gsi); gsi_next(&gsi)){
                                        gimple_stmt_cnt++;
                                }
                        }

                        if(dump_file){
                                fprintf(dump_file, "=== Function %d Name '%s' ===\n"
                                                "=== Number of Basic Blocks: %d ===\n"
                                                "=== Number of GIMPLE statements: %d ===\n\n", ++func_cnt, node->name(), bb_cnt, gimple_stmt_cnt);
                        }

                }
                if(dump_file){
                        fprintf(dump_file, "\n\n### End diagnostics, start regular dump of current gimple ###\n\n\n");
                }
                return 0;
        }
};

}

//Custom pass creation function
gimple_opt_pass* make_pass_ayoung(gcc::context* ctxt){
        return new pass_ayoung(ctxt);
}

Integrating the Pass

I integrated the pass into GCC's build sequence by modifying the following files:

1. passes.def

  • Inserted: NEXT_PASS (pass_ayoung);

2. Makefile.in

  • Configure the build using

 ~/gcc/configure --prefix=$HOME/gcc-test-001

  • It generates the final Makefile in the build folder, streamlining GCC compilation with make or make install. We modify Makefile.in by adding our pass's object file (e.g., pass_ayoung.o \) to the OBJS list

       

3. tree-pass.h

  • tree-pass.h registers passes for the GCC pass manager. To make our pass recognized, we declare it in register_pass_info. As a GIMPLE pass, it is added at the end of the GIMPLE passes, right before the IPA passes, following the required format:

extern gimple_opt_pass *make_pass_ayoung (gcc::context *ctxt);

Building the GCC

Let's rebuild the GCC!

Now that everything is set, it’s time to rebuild GCC and test the changes. Since we modified Makefile.in, we need to regenerate the Makefile to include our custom pass. The simplest method is to delete the existing Makefile and re-run the configuration script:

rm Makefile
~/gcc/configure --prefix=$HOME/gcc-test-001

I rebuilt GCC with:

time make -j$(nproc) |& tee build.log

Build result:

2 Errors were reported causing the process to terminate:      

The build failed because of those two configuration errors. Modifying the build system helps to clean and rebuild everything from scratch. Let’s break it down:

1. Clean the Build

First, remove the broken build directory:

rm -rf ~/gcc-build-001
2. Recreate the Build Folder
mkdir ~/gcc-build-001
cd ~/gcc-build-001

3. Configure GCC

 ~/gcc/configure --prefix=$HOME/gcc-test-001
       
4. Compile the Build

Use -j with the number of CPU cores (e.g., 24 for a fast build):

time make -j 24 |& tee build.log
Inspect the build again:
less build.log

Looks like the build was successful. It took 48m3sec to complete and no errors were reported.





5. Install the build:

make install 

Testing the custom gcc!

Test the Custom GCC by updating the path variable to see if we are using a custom gcc build:

 export PATH=$HOME/gcc-test-001/bin:$PATH
Check it’s using the right compiler:
which gcc

It should point to ~/gcc-test-001/bin/gcc.

and...

 it is! 

To test the pass, I compiled a sample C program (add.c):

#include <stdio.h>

void test_function() {
    int x = 21;
    int y = x + 9;
    printf("Result: %d\n", y);
}

int main() {
    test_function();
    return 0;
}

We need to write our output in a dump file:

gcc -Wall -g -fdump-tree-pass_ayoung add.c -o add

To ensure the pass works as expected, I compiled a simple test program and applied the GCC pass to it. The program's purpose was to call a basic function, which the pass would then analyze.

When I compiled this program with my custom pass enabled, the output included the expected results, showing the function name, the count of basic blocks, and the count of GIMPLE statements.

Output from the Pass

Here is an example of the output generated during the compilation process:



This demonstrates that the pass is working correctly by printing the name of the function (test_function), counting the basic blocks (2 in this case), and counting the GIMPLE statements (4).


Details of the Fix

  • Diagnostic Output: The pass now explicitly outputs to stderr, which captures all the required details (function names, basic block counts, and GIMPLE statement counts).
  • Testing Environment: I compiled the test program using the modified GCC with my pass included, ensuring that the pass was executed during the compilation process.

Conclusion

This project has been an insightful learning experience. I learned a great deal about the internals of the GCC compiler and how to develop custom passes. One challenge was ensuring the pass would output the required information correctly, which required careful testing and debugging.

Moving forward, I plan to extend this pass to perform more advanced analysis and integrate it further into GCC's optimization workflow. I am also interested in exploring how different GCC passes interact and how I can modify or extend them to achieve more complex optimizations.

I hope this post demonstrates that my GCC pass is now functioning correctly, producing the required output as per the project specifications. The changes I made to ensure proper output generation and testing provide the necessary evidence for this.

Thank you for reviewing this supplemental post. I look forward to your feedback!

Comments

Post a Comment

Popular posts from this blog

Project Stage 1

-
Image
 Introduction This project focuses on creating a custom pass for the GCC compiler, which will analyze functions during compilation. The pass will iterate through functions in the compiled code, print their names, count the number of basic blocks, and count the number of GIMPLE statements. Step 1: Creating the GCC Pass Creating the Pass File I navigated to the gcc/ directory inside the GCC source tree and created a new file: [ ayoung54@aarch64-002 ~]$ cd ~/git/gcc/gcc [ayoung54@aarch64-002 gcc]$ nano a_pass.cc Implementing the Pass I added the following code to define my custom GCC pass in a_pass.cc: #include   "config.h" #include   "system.h" #include   "coretypes.h" #include   "backend.h" #include   "tree-pass.h" #include   "pass_manager.h" #include   "context.h" #include   "diagnostic-core.h" #include   "tree.h" #include   "tree-core.h" #include   "basic-block.h" #include   ...
Read more

Lab05 - x86_64

-
Image
Objective:   In this lab, I worked with 64-bit assembly language on x86_64 platform to learn about CPU architecture and assembly instructions. Getting Started with Code Example   The first step is to retrieve the code example from the server. The file is compressed, so we'll extract it into the desired location (in my case, the home directory): cd ~ tar xvf /public/spo600-assembler-lab-examples.tgz Once extracted, you’ll see a folder named  spo600 , which contains all the necessary files. x86_64: Investigating the C Code To explore the C version of the program, navigate to the folder containing the  hello.c  file and compile it using  make : make x86_64:  Disassemble the binary to view the assembly code: objdump -d hello x86_64: This will show us the assembly instructions, where we can observe that different CPU architectures (x86_64 vs Aarch64) generate different instructions, even for the same program. Exploring the x86_64 Platform Now, let’s dive in...
Read more

Lab 03 - 6502 Program Lab (Revised)

-
Worm Game In this lab, I coded a game that would work within the 6520 Emulator while meeting specific criteria, including output to both the character and graphic screens, accepting keyboard input, and utilizing mathematical operations like addition and subtraction.  While building a classic worm game in Assembly, I ran into a few tricky errors that took some time to figure out. I want to share those mistakes and how I fixed them so you can avoid the same headaches.  On one particularly long night of coding, I decided to take on the challenge of re-building a classic Worm game! This game would be simple yet engaging, utilizing both the character screen and graphic screen for a fun experience. I found that  Specification The game starts with a worm moving across the screen, which is controlled using the keyboard. The worm body grows every time it "eats" a fruit, which is randomly placed on the screen. The user can control the worm's movement by pressing the W , A , S , or ...
Read more