Automatic Function Multi-Versioning for GCC

Introduction:

For this project, I will be working with the GCC compiler and learning how it works by building it from scratch on an AArch64 platform (which is 64-Bit). Setting up GCC like this lets me dig into how it compiles code and optimizes functions for different CPUs, especially as the goal is to experiment with Automatic Function Multi-Versioning (AFMV).

Guide to Building GCC for AArch64

Step 1: Cloning the Source Code

To get started, I needed the GCC source code. Cloning from the official GCC repository keeps things organized and up to date.

Here’s the command to clone it:

git clone git://gcc.gnu.org/git/gcc.git ~/gcc

This creates a directory called ~/gcc, where all the source files are stored. The cloning process might take a few minutes, depending on your internet speed.


Step 2: Setting Up a Build Directory

It’s recommended to create a separate directory for building GCC instead of doing it directly in the source directory. This keeps things organized.

Commands:

mkdir ~/gcc_build
cd ~/gcc_build

Now I’m in the gcc_build directory, ready to start configuring the build.

Step 3: Configuring the GCC Build

Next, I set up the configuration for GCC with a custom install path. This way, I can install GCC without overwriting the system’s default version.

Command:

~/gcc/configure --target=aarch64-linux-gnu --prefix=$HOME/gcc-test-1 --enable-languages=c,c++
  • --target=aarch64-linux-gnu sets GCC up to build specifically for AArch64.
  • --prefix=$HOME/gcc-test-1 tells it to install in ~/gcc-test-1 , keeping it separate.
  • --enable-languages=c,c++ limits it to C and C++ (just to make the build faster).

Step 4: Starting the Build Process

Building GCC is requires good amount of processing speeds, so I ran the make command with -j to set up parallel jobs (one job per CPU core, plus one).

Command:

time make -j 13 |& tee build.log

Explanation:

  • time tracks how long the build takes.
  • -j 17 runs 13 jobs at once (I’m using a 12-core server).
  • |& tee build.log saves the output and errors to build.log, which helps if there are any issues.
Device Specs:
  • CPU: Intel Core i7-10750H
  • OS: Windows 11
  • Build Time: ~1.5 Hours

Step 5: Installing GCC Locally

Once the build completed, I installed GCC in the custom directory specified during configuration. Since this is a local install, there’s no need to use sudo.

Command:

make install

This installs GCC into ~/gcc-test-1, so I can use it without affecting any system files.

Step 6: Setting Up the Custom GCC Build

To make my terminal recognize the new GCC build as the default, I added its bin directory to the PATH.

Command:

export PATH=$HOME/gcc-test-001/bin:$PATH

To confirm that my system recognizes gcc, I used this command:

gcc --version



Reflection: 

The thought of building GCC from scratch felt a bit overwhelming. I knew I’d be dealing with complex processes and that there would probably be a few challenges along the way, especially with my limited experience in setting up compilers. But once I got started, it wasn’t as daunting as it seemed, and working through each step helped me gain a much clearer understanding of how compilers actually work.
One of the most valuable parts was exploring the various dump options. These dumps offered a peek into each stage of compilation and showed me exactly how GCC optimizes and processes code.
I ran into some issues with configuring the build environment and making sure my custom GCC version was recognized by the system, but once I got it working, I could see the steps more clearly.


Comments

Post a Comment

Popular posts from this blog

Building GCC Part 2

This is my attempt to learn and work with GCC as part of my SPO600 course. I’m working on Stage 2 of the project, where I have to create and test a Clone-Pruning Analysis Pass. You can find the first part in my blog page. Creating the Dummy Pass I started by creating a basic pass that should iterates through the program functions and output their names to a dump file.  Iterating Through GIMPLE Statements Next, I added logic to traverse the GIMPLE representation of each function. GIMPLE is an intermediate language used by GCC, and understanding it was crucial for the project. By iterating over the GIMPLE statements within each basic block, I could analyze the structure of functions. This step highlighted the importance of diagnostic dumps, as they provided a detailed view of what the pass was processing. While the GIMPLE code initially felt overwhelming, breaking it down into smaller sections made it easier. Setting Up The first step was to get the provided files into my working dir...
Read more

Wrapping Up Project : Stage 3

With the final stage of the SPO600 project, my journey into the GCC compiler comes to a close. This stage was all about tying up loose ends from Stage 2, testing the Clone-Pruning Analysis Pass, and reflecting on what I’ve learned throughout the project. Progress Overview The focus of Stage 3 was to finalize the work I started in Stage 2. Building on my earlier implementation, I managed to create a pass that iterates through functions, analyzes their GIMPLE representations, and outputs information to a dump file. Here's what my custom GCC pass can now do: Print Function Names : The pass successfully identifies and prints the names of all functions. Output GIMPLE Statements : It iterates through the GIMPLE representation of each function, printing the statements to the dump file. Count Statements : The pass tracks and stores the number of GIMPLE statements for each function. A snippet of my pass code from tree-ctyler.cc demonstrates the approach: unsigned int pass_ctyler::execute(fu...
Read more