DEV Community: Yukti Manoj Mulani

Project Stage-3: Reflections and Final Thoughts on Implementing AFMV in GCC

Yukti Manoj Mulani — Fri, 21 Jun 2024 23:50:08 +0000

As the summer project for SPO600 comes to a close, it’s time to reflect on the journey of implementing Automatic Function Multi-Versioning (AFMV) for AArch64 systems in GCC. This final blog post summarizes the accomplishments, challenges, and learnings from this project, and provides insights into the future work that could enhance this feature further.

Project Overview and Contributions
Over the course of this project, my primary focus was on extending GCC to support AFMV, particularly with features like SVE2 for AArch64 processors. AFMV aims to provide performance optimizations by automatically creating function clones optimized for different processor features, enabling the software to dynamically choose the most efficient version at runtime.

Key Contributions:

Enhanced the GCC’s multiple_target.cc file to recognize and handle SVE2 attributes effectively.
Integrated advanced GCC flags to support the SVE2 instruction set.
Addressed and resolved critical errors related to attribute recognition in GCC.

Code Location and Integration:

Repository Branch: The changes were committed to the 2024-S-FMV-automatic-function-cloning branch in the class Git repository.
File Location: The specific changes were made in gcc/gcc/multiple_target.cc.

Integration with Other Branches:

The 2024-S-FMV-automatic-function-cloning branch was regularly rebased with the main development branch to ensure compatibility and to integrate the latest updates from other team members working on related tasks.
Collaboration with other contributors was key to integrating AFMV with various diagnostic and function pruning tools being developed concurrently.

What Works and Achievements

Successful SVE2 Integration: By using advanced GCC flags, I was able to enable SVE2 support, which allows for greater optimization potential in function cloning and selection.
Improved Attribute Handling: The modifications made to multiple_target.cc ensure that attributes like target("sve2") are now valid and properly handled by the compiler.
Enhanced Performance Diagnostics: The project also contributed to improved diagnostic outputs that help developers understand the effects of function multi-versioning and optimize their code more effectively.

Limitations and What Needs Improvement:

Limited Testing Scope: Although the project saw significant progress, the testing was limited to specific cases and hardware. More extensive testing across diverse AArch64 systems is needed.
Error Handling and Debugging: While some critical errors were resolved, the handling of complex attribute combinations still requires refinement. Future work should focus on improving the robustness of error handling.
Documentation and Usability: Although I updated the documentation to some extent, it needs to be more comprehensive to assist new users and developers in understanding and utilizing the AFMV feature effectively.

What Was Not Tested:

Cross-Platform Performance: The testing primarily focused on AArch64, and the performance and functionality on other platforms like x86_64 need to be evaluated.
Complex Use Cases: The project didn’t extensively cover complex real-world applications that could benefit from AFMV, such as those requiring intricate multi-core or SIMD optimizations.

Reflections on the Project and Course
This project has been an incredible learning experience, providing deep insights into the workings of GCC and the intricacies of compiler design. Here are some key takeaways:

Understanding Compiler Internals: The hands-on experience with GCC’s codebase was invaluable. It enhanced my understanding of how compilers manage attributes, perform optimizations, and generate machine-specific code.
Challenges of Multi-Versioning: Implementing AFMV highlighted the complexities involved in function cloning and optimization, especially when dealing with diverse processor features and instruction sets.
Collaborative Development: Working in a team environment and integrating code from multiple branches taught me the importance of version control, code reviews, and effective communication.
Balancing Performance and Compatibility: The project underscored the delicate balance between optimizing for the latest hardware features and maintaining compatibility with older systems.

Next Steps:

Moving forward, I plan to continue refining the AFMV implementation, focusing on:

Extending testing to cover more platforms and use cases.
Improving documentation to facilitate broader adoption and usage.
Collaborating with the GCC community to integrate these changes into the main GCC branch.

This project has been a rewarding journey, filled with both challenges and achievements. I am grateful for the opportunity to contribute to such an important tool in the open-source community and look forward to continuing this work in the future.

For those interested, the code and changes are available in the 2024-S-FMV-automatic-function-cloning branch in the class Git repository.

Until next time, happy coding 🚀!!

Project Stage-3:Leveraging Advanced GCC Flags.

Yukti Manoj Mulani — Fri, 21 Jun 2024 23:18:33 +0000

Hello there!!

As our journey towards implementing Automatic Function Multi-Versioning (AFMV) for AArch64 systems continues, I’ve encountered some intriguing challenges and solutions regarding the support of SVE2 (Scalable Vector Extension version 2) in GCC. This blog post explores how advanced GCC flags can be leveraged to overcome these hurdles, enabling a smoother path towards a fully functional AFMV setup.

Exploring Advanced GCC Flags:

GCC (GNU Compiler Collection) is known for its robust support for various architectures and instruction sets, including SVE2. However, enabling these features sometimes requires explicit configuration through advanced flags. Here’s a breakdown of the steps I followed to integrate these features:

1. Identifying the Required Architecture Support:

The error indicated that SVE2 support wasn't automatically enabled, which led me to investigate the necessary architecture flags. SVE2 is part of the Armv8.5-A architecture, so I needed to ensure GCC was configured to support this.

2. Adding the Appropriate Flags:

By consulting the GCC documentation and community forums, I identified the necessary flags to enable SVE2 support. The critical flags were -march and -mcpu, which dictate the target architecture and CPU:

gcc hello.c -o hello -O3 -march=armv8.5-a+sve2 -mcpu=cortex-a75

Here’s a brief explanation of the flags:

-march=armv8.5-a+sve2: Specifies the target architecture, including SVE2.
-mcpu=cortex-a75: Specifies the CPU, ensuring that it aligns with the required architecture.

3. Integrating the Flags into the Build Process:

By incorporating these flags into my build commands, I ensured that the compiler was correctly configured to recognize and support the SVE2 instructions. This involved updating my Makefile and build scripts to include these flags.

4. Validating the Configuration:

After adding the flags, I recompiled my code and verified that the target("sve2") attribute was now recognized and valid. Here’s a snippet of the updated hello.c:

#include <stdio.h>

__attribute__((target("sve2")))
void my_function() {
    printf("This function utilizes SVE2 instructions.\n");
}

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

Insights and Learnings:

This experience underscored the importance of understanding and leveraging advanced GCC flags to achieve the desired functionality. It was a reminder that while GCC is incredibly powerful, it often requires explicit configuration to support specialized features like SVE2.

In summary, the addition of advanced GCC flags was crucial in enabling SVE2 support, thereby allowing us to move forward with the AFMV implementation. This journey has been instrumental in deepening my understanding of compiler configurations and their impact on project outcomes.

Stay tuned for the next post in this series, where I’ll delve into the performance optimizations made possible through AFMV and SVE2!

Until next time, happy coding 🚀!!

Project Stage-3: Overcoming Compiler Attribute Challenges

Yukti Manoj Mulani — Fri, 21 Jun 2024 23:05:11 +0000

Welcome back folks!! In our quest to implement Automatic Function Multi-Versioning (AFMV) for AArch64, one of the critical challenges has been dealing with compiler attribute errors. The target("sve2") attribute error was a particular stumbling block. Here’s how I tackled it.

Initial Error Message:

error: pragma or attribute ‘target("sve2")’ is not valid

Steps to Resolve:

1. GCC Version and Compatibility Check:

Verified that my GCC version supports SVE2 with gcc --version.
Updated GCC to the latest version to ensure full support for the attribute.

2. Correct Usage of Attributes:

Adjusted the context in which the target attribute was applied, ensuring it was used correctly in the function definition.

3. Compilation Flags:

Added -march=armv8.5-a+sve2 to the GCC command to explicitly enable SVE2 support.

4. Code Adjustment:

#include <stdio.h>

__attribute__((target("sve2")))
void my_function() {
    printf("This function uses SVE2 instructions.\n");
}

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

With these adjustments, the attribute error was resolved, allowing me to continue with the AFMV implementation. This process underscored the importance of aligning compiler settings with the specific architectural requirements.

Until next time , happy coding 🚀!!

Project Stage-3: Digging Deeper

Yukti Manoj Mulani — Fri, 21 Jun 2024 22:43:26 +0000

Hi Peeps!! Welcome back. Without wasting any time lets continue from the last blog.

The error message related to the target("sve2") attribute has been a key focus in the latest phase of our AFMV implementation. The message was clear but presented a challenge:

error: pragma or attribute ‘target("sve2")’ is not valid

To address this, I first ensured that my GCC version supports SVE2 instructions. Using the command gcc --version, I verified the version and compatibility. Here’s what I found:

GCC Version Check: Confirmed that my GCC version was up-to-date and should theoretically support SVE2.

Next, I explored the usage and context of the target attribute. Here’s a snippet from my hello.c file:

#include <stdio.h>

__attribute__((target_clones("sve2")))
void my_function() {
    printf("This function uses SVE2 instructions.\n");
}

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

Despite the correct syntax, the error persisted. This led me to check if there were specific flags required to enable SVE2 support. The solution involved adding -march=armv8.5-a+sve2 to the GCC compilation command:

gcc hello.c -o hello -O3 -march=armv8.5-a+sve2

This resolved the issue, confirming that the attribute was now valid under the specified architecture. The journey continues, but this was a significant step towards a functioning AFMV implementation.

Until next time, happy coding 🚀!!

Project Stage-3: Error Analysis

Yukti Manoj Mulani — Fri, 21 Jun 2024 22:29:50 +0000

Hi folks!!! Welcome to my series of Summer Project blogs. As part of the SPO600 2024 Summer Project, my objective in Stage 3 is to resolve Automatic Function Multi-Versioning (AFMV) error messages within the GNU Compiler Collection (GCC). AFMV is a cutting-edge feature designed to optimize function calls across different micro-architectural levels, making software more adaptable and efficient on various hardware platforms.

The goal of this stage is to ensure that the AFMV implementation in GCC functions seamlessly by identifying, analyzing, and resolving error messages that arise during its use. This post will introduce the scope of Stage 3, highlight the challenges of dealing with AFMV error messages, and outline the approach for resolving these issues.

Error Messages Context:

Automatic Function Multi-Versioning (AFMV) allows for the creation of multiple versions of a function, optimized for different hardware features, without requiring changes to the source code. This capability significantly enhances software performance by leveraging the latest hardware optimizations automatically.

However, implementing AFMV comes with its own set of challenges. One major issue is the occurrence of error messages that can be cryptic and difficult to understand, making it challenging to troubleshoot and fix problems. These errors can arise from various sources, such as syntax issues, misconfigurations, or conflicts with other compiler features.
The error message that is troubling us is like so-

Initial Challenges:

The main challenge in this stage is the complexity of the AFMV feature and the intricacies of the GCC codebase. Error messages in GCC can be quite specific and may involve multiple components of the compiler. Understanding the context in which these errors occur is crucial for effective resolution.

Additionally, some error messages may not directly point to the root cause of the issue, requiring a thorough investigation and sometimes even modifying the compiler's internal mechanisms to achieve a fix. This stage is not just about fixing bugs but also understanding how AFMV integrates into the broader GCC architecture.

Goals for Stage 3:

The primary goals for this stage are:

Identify Error Messages: Categorize and document the various AFMV-related error messages encountered during compilation.

Analyze Root Causes: Perform a deep dive into the causes of these errors, identifying any common patterns or recurring issues.

Resolve Issues: Implement fixes for these errors, ensuring that AFMV functions correctly and efficiently within GCC.

Document Solutions: Provide detailed documentation of the errors and their resolutions to aid future development and troubleshooting efforts.

Integrate and Test: Ensure that the solutions are integrated into the main codebase and thoroughly tested for robustness.

Summary:

In the following blog posts, I will delve deeper into the specifics of AFMV errors, the strategies used to resolve them, and the testing processes involved. This journey is not just about solving problems but also about enhancing our understanding of GCC and contributing to a more efficient and flexible compiler.

Stay tuned as we explore the fascinating world of AFMV and GCC error handling in more detail.

Project Stage-2 Implementation Part-3

Yukti Manoj Mulani — Tue, 18 Jun 2024 21:00:41 +0000

Welcome back, everyone! In the previous part of this series, we delved into the complexities of Function Multi-Versioning (FMV) and started exploring the depths of GCC's inner workings. After painstakingly investigating files like tree.h, tree.cc, and tree-inline.h, we honed in on the elusive function responsible for FMV: expand_target_clones in multiple_target.cc.

Unpacking the Errors: Invalid Target Attributes

As I ventured deeper into the code, modifying the expand_target_clones function to automatically create function clones for various target architectures, I encountered a persistent error that quickly turned my excitement into frustration:

error: pragma or attribute ‘target("sve-bf16")’ is not valid

Despite my best efforts to resolve this error, it remained stubbornly present. This error indicates that the specified target attribute isn't recognized or supported by my current GCC setup.

Diagnosing the Error: Why It Happened

This error message typically arises when:

Unsupported Target Architecture: The specified target attribute is not supported by the GCC version being used.
Incorrect Attribute Syntax: The attribute might be formatted or spelled incorrectly, causing GCC to reject it.

Steps Taken to Resolve the Error

To tackle this issue, I followed a structured approach to diagnose and attempt to resolve the problem

1. Verify Supported Target Attributes

First, I needed to determine which target architectures were actually supported by my GCC version (11.3.1). I used the command below, which is intended to list all valid target architectures:

gcc -E -march=help -xe /dev/null

However, this command resulted in an error:

gcc: error: unrecognized command line option ‘-march=help’

Despite the error, it hinted at valid target architectures. Knowing that my GCC version was 11.3.1, I needed to cross-reference the valid targets for this version.

2. Cross-Check GCC Documentation

I reviewed the official GCC documentation for version 11.3.1, which provides comprehensive information on supported target architectures. This step was crucial in understanding which attributes were valid for the version I was using.

3. Update Hardcoded Attributes

With the correct list of supported targets, I revised my hardcoded attributes to include only those that were valid. Instead of sve-bf16, I opted for more widely supported attributes like sve and sve2:

const int num_attrs = 2;
char attrs2[num_attrs][5] = {"sve", "sve2"};

Despite this change, the error persisted.

Further Investigations and Continued Errors

Even after updating the attributes, the error did not disappear. This was a significant setback, but it also provided an opportunity to deepen my understanding of the issue.

1. Examine CPU Features

I examined the /proc/cpuinfo file to understand the supported features of my CPU. This information helped confirm that the hardware supported the attributes I was attempting to use.

cat /proc/cpuinfo

However, this did not shed light on why the compiler continued to reject the target attributes.

2. Investigate GCC Configuration

I reviewed the GCC configuration to ensure that it was built with support for the architectures I was targeting. Ensuring that the compiler itself was correctly configured was essential, but it did not resolve the error.

3. Seek Insights from Community Resources

I turned to forums and mailing lists where other developers had discussed similar issues. While there were many insights, none directly addressed the persistent error I was encountering.

Key Takeaways and Next Steps

This part of the project was filled with challenges, highlighting the complexities of compiler development. Here are the key takeaways from this experience:

Persistent Errors Are Learning Opportunities: While frustrating, persistent errors offer a chance to deepen your understanding and refine your approach.
Documentation and Community Insights Are Valuable: Reviewing documentation and seeking community insights can provide guidance, even if they don't always offer immediate solutions.
Next Steps: A Plan for Resolving the Error
Given the persistent error, here are the steps I plan to take next:

1. Verify GCC Build and Configuration

I will verify that my GCC build includes the necessary support for the target attributes. This involves checking the configuration and potentially rebuilding GCC with the required features.

2. Test with Different GCC Versions

Testing with different GCC versions may help identify if the issue is specific to version 11.3.1. This could provide insights into whether a version upgrade or a different build is necessary.

3. Explore Alternative Architectures

I will explore using alternative target architectures that are widely supported and verified to work with my setup. This may involve testing with simpler or more generic attributes initially.

4. Debug with Detailed Logging

I will enable detailed logging and diagnostics in GCC to better understand why the error occurs. This may involve using flags or modifying the GCC code to provide more information during compilation.

Wrapping It Up: Lessons Learned and Moving Forward
Despite the persistent error, this project has been a valuable learning experience. It has highlighted the importance of persistence, attention to detail, and the value of community and documentation in tackling complex issues.

As I continue to work through these challenges, I am optimistic that the next steps will provide the insights needed to resolve the error and successfully implement the automatic FMV cloning feature.

Thank you for joining me on this journey. Stay tuned for more updates as I continue to unravel the mysteries of GCC and FMV. Happy coding! 🚀

Project Stage-2 Implementation [part-2]

Yukti Manoj Mulani — Fri, 14 Jun 2024 22:53:24 +0000

Welcome back peeps!! After a lot of theory about function multi versioning in the last blog we will start actually working on it in this part. So, without wasting any time lets get started.

I started with exploring files like
tree.h,tree.ccand tree-inline.h
to understand how functions are represented and cloned in GCC's gimble IR. Now the question is how do I find them. So I used the following commands and experimented with the arguments here and there and came up with the following.
Syntax
find /path -iname filename
This was the actual command I used
find ./ -iname tree.h
The file tree.his in gcc/gcc/tree.h To view thw contents of the file we can use the command cat tree.h

After taking time to investigate the file I found out that the file contains code to help around function multiversioning and deaclares those functions but does not contain the code that is used to create clones.
Now lets explore other files.This time lets use the vim editor to read the file which make it a little easy ti read.The commanf for that is :-
vi tree.cc
This file is also lacated in the /gcc/gcc/ directory.
This file does not look very useful because it contains code for the tree structure and not multi versioning.

Now explore the third file tree-inline.h. Using the same command for vim editor. To exit vim editor without saving anything, use the command.:Q!

This file contains code related to inlining, versioning, cloning, and parallelization. The presence of these keywords made me feel that I am close to the actual code where turning AFMV on and passing the target architectures array is located.

If you want to search for a keyword in vim editor, just type.
/word
I searched for the word version by using /version and found the declaration of the function called
bool tree_versionable_function_p(tree);
This function was declared under the comment
"/*function prototypes*/".
By the declaration and the name, it seems that this function determines whether the code is versionable or not. A few more commands that I tried to find the actual code were following.

grep "clon" -r
This commands grabs all the files containing the word "clon". It gace an ecdless list of files making it impossible to indentify

grep "fmv" -r
this gave me a shorter list but no results.(had a mental breakdown but I continues 😵‍💫)

git log --oneline --grep="multiversioning"
This command gives you all the past commits displayed in one line containing the word "multiversioning". I got arounf 17 commits and 3 of them were useful.

The commits are as follows.

The ones that I founf usefule were
"[aarch64] Add function multiversioning support"
"Add support for target version attribute"
"aarch64: Fix function multi versioning mangling "

I investigated the first two commits and I could not find very useful code, but I needed to investigate these two commits to get an idea of how things work and how the function multi versioning is done. I investigated the first two and went off track forgetting that we need to update and not add FMV. Then I came to the third commit.
To investigate any commit you can use the command.
git show <commit hash>
After investigating this commit, you will see there are few lines that tell you which files were changed. And the address of the file. I tried to use the command grep "target_clones". But it froze my session. The correct way to do the grep along with the commit is the following.
git show <commit hash> | grep "taget_clones"

This is called piping. This gave me all the lines where the target clones were specified before the function. Now we need to find the function that contains the code for automatic FMV. Then I searched up the word clone and after so many occurrences I found a comment.
/*If the function in the node has multiple target attributes, create the appropriate clone for each valid target.*/
The function definition looks like the following.

statuc bool expand_target_clones(struct cgraph_nodes*node, bool definition)

This function takes in an array of target clones and the function definition to be cloned. It parses the comma separated target clones and verifies if the function is versionable by using the function that we discovered previously.

tree_versionable_function_p

Cannot believe that it took me so much time. I was always searching for files with obvious names. But the actual file that was useful was /gcc/gcc/multiple_targets.cc
Then I started my work and hardcoded the array of target architectures needed and also made the definition being passed to be true to apply function multi versioning for all functions automatically.

So now we need to test it. So I wrote a simple sum of array program and built it using O3 level optimization

First I set the hard coded targets to be sve and sve2, but the program that I designed to test it did not compile because the target sve2 is not supported by GCC version 11.3.1. Which is the version that I'm using right now.

So to know which targets are supported, I used the following command.

gcc -E -march=help -xe /dev/null

But this command gave me an error, but it told me which targets are valid. And are supported target architectures by my current GCC version.

Then I changed the hardcoded array to the preferred targets. Still I got the same error.

So now I checked the file CPU info which is under the directory proc. And this file gave me the features of every processor. And also told me what all features are supported by each processor.

Wrapping It Up: A Roller Coaster Ride in Code Land

After navigating through a labyrinth of files, parsing through oceans of code, and deciphering the cryptic hieroglyphics that is GCC's inner workings, I finally emerged victorious! 🎉 Although I did face some hiccups with target architectures and GCC versions (who knew “sve2” was such a stickler for attention?), I’m now armed with knowledge and a few more grey hairs.

Key Takeaways:

Persistence Pays Off: It took a while to locate the right file (/gcc/gcc/multiple_targets.cc), but persistence led me to the treasure chest of FMV code.
Tools are Your Friends: Commands like grep, find, and git show became my trusty sidekicks in this quest. (Seriously, I might name my next pet “grep”.)
Know Your Limits: GCC version 11.3.1 has its own quirks, and knowing what your tools can and cannot do is half the battle.

Lessons Learned:

Stay Curious: Digging through the commits and code not only helped me understand FMV better, but also improved my detective skills (move over, Sherlock!).
Stay Organized: Keep track of useful commands and file paths. It saves time and sanity in the long run.
As I wrap up this chapter of my FMV journey, I look back and chuckle at the moment when I almost turned my keyboard into a Frisbee. 🥏 But hey, no keyboards were harmed in the making of this blog!

What’s Next?

Next up is testing the FMV with different GCC versions and refining my approach to cater to all the architectures out there (yes, even the picky ones like “sve2”). I’ll also be looking into more advanced optimizations and perhaps dabbling in some parallel processing fun.

Stay tuned, dear readers, as I continue to unravel the mysteries of function multi versioning. And remember, if you ever find yourself lost in a sea of code, just keep swimming… and maybe bring a snorkel. 🏊‍♂️

Reflections:

This project was like a wild roller coaster ride—thrilling, sometimes dizzying, but ultimately satisfying. I’ve learned so much about GCC’s inner workings and realized that there’s always more to explore and improve. I plan to dive deeper into compiler optimizations and perhaps even contribute to the community.

Links to My Code:

Thank you for joining me on this journey. Until next time, happy coding! 🚀

Function Multi-Versioning: The Swiss Army Knife of Code

Yukti Manoj Mulani — Fri, 14 Jun 2024 21:21:45 +0000

Hey tech tribe! 🗡️

Let’s talk about something that’s got all the versatility of a Swiss Army knife – Function Multi-Versioning (FMV).I know I have talked about it before but trust me it is different this time. It’s not just a fancy term; it’s a game-changer for developers juggling different CPU architectures.

Imagine you’re at a cook-off, and you’ve got to make a dish that impresses every judge with their unique tastes. That’s what FMV does for your code. You write a function, and FMV makes sure it’s the best darn function for every kind of CPU it might run on. Whether it’s x86-64 or aarch64, FMV has got you covered. It’s like having a single knife that can slice, dice, chop, and julienne – all with perfect precision! 🔪

There are a few ways to use FMV. You can manually create different versions of your functions, or let the compiler do the heavy lifting with something called automatic cloning. It’s like having a sous-chef who not only preps all the ingredients but also makes sure every dish is seasoned to perfection.

Our ultimate goal? To implement Automatic Function Multi-Versioning (AFMV) in GCC for aarch64. It’s the next evolution of FMV, making sure that your software isn’t just good, but great, no matter where it runs.

So, here’s to FMV – the Swiss Army knife in your coding toolkit, ensuring your code is always sharp and ready to impress! 🥳

Automatic Function Multi-Versioning: The Lazy Programmer’s Dream!

Yukti Manoj Mulani — Fri, 14 Jun 2024 21:14:08 +0000

Hey there, code wizards! 🧙‍♂️

Imagine a world where you write a piece of code, sit back, and the computer magically makes it work on all kinds of different hardware. Sounds like a dream, right? Well, say hello to Automatic Function Multi-Versioning (AFMV) – the lazy programmer’s dream come true! 🌟

In our quest to make GCC (GNU Compiler Collection) smarter, we’re implementing AFMV for the aarch64 architecture. What does this mean? It’s like having a genie who clones your functions into multiple versions, each tailored for different micro-architectural features. You don’t have to lift a finger (well, except for typing the initial code, but let’s not get picky!).

Here’s the deal: normally, you’d have to write different versions of your functions to cater to various CPU features. It’s like making different kinds of pizzas for people with different tastes. One for the spicy lovers, one for the cheese enthusiasts, and one for the pineapple-on-pizza weirdos. 🍕 With AFMV, the compiler does this for you! It’s the ultimate life hack for programmers, reducing the time spent tweaking code for different hardware.

So, next time you’re coding, remember that AFMV is like having your own personal genie in a bottle. Just make sure not to wish for infinite loops – those never end well!

Thank you for reading!! Until next time happy coding!!🚀

The Juggling Act of Multiple Architectures

Yukti Manoj Mulani — Fri, 14 Jun 2024 21:09:58 +0000

Hey, folks! 🤹‍♂️

Ever tried juggling flaming swords while riding a unicycle? No? Well, that’s pretty much what handling multiple computer architectures feels like! In our Software Portability and Optimization course, we’re diving deep into the world of x86-64 and aarch64 architectures. They’re like the Batman and Robin of computing, each with their own unique set of tricks and tools.

These architectures come with a smorgasbord of micro-architectural features. Think of these as special moves in a video game – from cryptography acceleration to SIMD capabilities, each feature is like an extra power-up. But here’s the kicker: not all processors have all the features, so coding for them is like trying to write instructions for a treasure hunt in a mansion, not knowing if everyone has the same map!

If you write software that relies on a feature not available on a user’s CPU, it’s game over. Literally. The software crashes. 💥 So, developers have to juggle – make the software flexible enough to run on any machine while also taking full advantage of any available superpowers.

Multi-versioning comes to the rescue! 🦸‍♂️ It’s like preparing multiple versions of our treasure hunt instructions, each tailored for different maps. Whether it’s Library Multi-Versioning (LMV) duplicating whole libraries or Function Multi-Versioning (FMV) creating multiple versions of functions, it ensures that no matter what CPU the user has, they get the best possible performance. Now that’s some serious juggling!

Thank you for reading.Until next time happy coding!!🚀

SIMD and SVE: The Superheroes of Speed!

Yukti Manoj Mulani — Fri, 14 Jun 2024 21:05:59 +0000

Hey there, fellow tech enthusiasts! 👋

Let’s talk about some true unsung heroes of the computing world – SIMD and SVE. No, they’re not the latest Marvel superheroes (though they might as well be!). These acronyms stand for Single Instruction, Multiple Data (SIMD) and Scalable Vector Extensions (SVE). If you’re scratching your head wondering what they do, imagine a superhero with the power to handle multiple tasks simultaneously with lightning speed! ⚡️

SIMD is like having a superhero team where each member can handle a different piece of the puzzle simultaneously, boosting performance without breaking a sweat. It’s a lifesaver when you’re dealing with large datasets, making your computer blaze through operations that would otherwise take forever.

But wait, there’s more! Enter SVE and its sidekick SVE2, extensions designed to make our CPUs even more flexible and powerful. They’re like upgrading your superhero team with new gadgets and powers, allowing them to tackle an even broader range of challenges. 🚀

So next time your computer zips through a complex task, give a nod to SIMD and SVE – the unsung heroes behind the scenes!

Project Stage-2 Implementation [part-1]

Yukti Manoj Mulani — Thu, 13 Jun 2024 18:38:46 +0000

Welcome to the SPO600 2024 Summer Project Stage-2! This summer, we're diving into the fascinating world of compiler optimization to build a prototype of Automatic Function Multi-Versioning (AFMV) for the GNU Compiler Collection (GCC) on AArch64 systems. In this blog, we’ll explore the context, for the Stage-2 of our project where we apply FMV to functions automatically, a key component of our project.

My Task

In this project we were assigned different roles since it is a very big process for every individual alone and we have less time. Imagine trying to understand the huge code base of GCC and then having almost 35 copies of the same project.😵‍💫
So now lets get to the point which is my task. I was assigned the task of applying FMV cloning to the functions automatically. Description: When the appropriate command-line options are provided, the compiler should automatically clone all functions, as if the target_clone attribute was specified.
Now I know what questions are coming up in your mind , What FMV
cloning actually is? and so on.
I you wanna know then join me for this mini trip of applying FMV cloning.
P.S. it might not be a "MINI" trip though.

What is Function Multi Versioning?

Function Multi-Versioning (FMV) is an optimization technique used in modern computing to enhance the performance of programs by allowing different versions of a function to be generated and used based on the specific characteristics of the hardware or runtime environment. This approach can lead to more efficient execution by leveraging specialized hardware features or optimizations tailored to specific conditions.

Key Concepts

Multiple Versions: FMV involves creating multiple versions of a function, each optimized for different hardware capabilities or runtime scenarios. For example, a function might have one version optimized for CPUs that support a specific set of vector instructions and another version for older CPUs without these features.
Selection Mechanism: At runtime, the system determines which version of the function to execute based on the current environment. This decision is typically made using a selector function that checks the hardware capabilities or other relevant factors.
Hardware Specialization: FMV is especially useful for exploiting hardware-specific features like vector extensions (e.g., AVX, SSE on x86 architectures) or specialized instruction sets available on newer processors.
Performance Optimization: By using the most appropriate version of a function for the given context, FMV can significantly improve performance, particularly in compute-intensive applications such as scientific computing, graphics processing, and machine learning.
Dynamic vs. Static Dispatch:

-Static Dispatch: The selection of the function version
happens at compile time. The compiler generates different
code paths depending on compile-time checks or target
specifications.

-Dynamic Dispatch: The function version is selected at
runtime
based on actual hardware detection or other runtime
conditions.
Compiler Support: Modern compilers, such as GCC and Clang, often provide built-in support for FMV. They allow developers to specify different versions of a function and handle the dispatch logic automatically.

Benefits of Function Multi-Versioning

Improved Performance : By using hardware-specific optimizations, FMV can enhance the execution speed of programs.
Flexibility: Programs can adapt to a wide range of hardware configurations without requiring multiple separate binaries.
Backward Compatibility: FMV allows newer code to run on older hardware by providing a version of functions that does not rely on newer, unsupported features.

Now the next critical question arises that how do we do this FMV cloning thing? So, as you know lets discuss this in the next blog 😉

Until then folks... Happy Coding!!!