RE-POST February: SPO600 Week 4 Part 1

This post would be about what I have learned during my fourth week of Software Portability and Optimization (SPO600) class.

GNU iFunc

Different Implementation of Same Architecture may have Different Capabilities

Compile-time codepath selection	Run-time codepath selection
has no runtime overhead	has runtime overhead
requires different binaries for different hardware	allows you to ship one binary for multiple hardware configurations

The ideal runtime codepath selection would take advantage of hardware (HW) capabilities with minimal overhead and minimal changes to code.

This is where GNU iFunc comes in. IFunc stands for indirect functions or indirect function calls.

A function pointer would be used and set up at runtime before executing the code. The functions that are marked as indirect functions would take a brief pause and analyze the HW capabilities and based on the HW, the function that would be implemented would be picked. To see how this works, go to the iFunc Demo post.

Function prototype with attribute:

returnType *name (params)  __attribute__((ifunc("resolver")));

Resolver:

static void (*resolver(void)) { return functionPointer };

How to Determine Capabilities of Current HW

1. Architecture-specific ways to query HW capabilities (CPUINFO)
2. getauxval() function - gets auxiliary vector data set up by the ELF loader

How do we test a SVE and SVE2 code when we don't have a machine for it?

• qemu-aarch64 which is an emulation

So if in the iFunc Demo post, we want to add the SVE and SVE2 capability, we can do the following command in the terminal:

qemu-aarch64 ./ifunc-test




As we can see here, the resolver is only called once again, however, now we see that the foo function is using the SVE2 implementation. This emulation does not take advantage of the performance of a real SVE and SVE2 system, however, it provides us an environment where we can do some testing.