Optimizing Function Pointers with `restrict`

The Problem: How Pointer Aliasing Ties the Compiler's Hands

First, let's define pointer aliasing: this occurs when two or more pointers hold the same memory address, meaning they refer to the same data.

Consider a simple function to add two arrays:

void vector_add(int n, int *result, const int *a, const int *b) {
    for (int i = 0; i < n; i++) {
        result[i] = a[i] + b[i];
    }
}

The compiler wants to optimize this loop. It might want to reorder the instructions, load multiple data elements at once using SIMD (Single Instruction, Multiple Data) instructions, or keep values in registers to avoid slow memory access.

However, the compiler must be conservative. What if the caller does this?
vector_add(N, my_array, my_array + 1, my_other_array);

Here, result and a point to overlapping memory regions. A write to result[i] (which is my_array[i]) could potentially change the value that will be read by a[i+1] (which is my_array[i+1]) in the next iteration. This potential for aliasing forces the compiler to generate slow, safe code. It must write result[i] to memory before it can safely read a[i+1], preventing many powerful optimizations.

The Solution: The restrict Contract

The restrict keyword, introduced in the C99 standard, is a contract you make with the compiler.

When you declare a pointer p as restrict, you promise that for the lifetime of p, any object accessed through p will only be accessed via p (or pointers derived directly from p). No other pointer in the same scope will be used to access that same object.

If you uphold this promise, the compiler can assume that different restrict-qualified pointers point to completely independent memory locations. This "no-aliasing" guarantee unlocks a new level of optimization.

Let's start by understanding the formal basis and the problem restrict solves.

If you break the restrict promise—for instance, by passing overlapping buffers to a function whose parameters are restrict—the behavior is undefined. The compiler is free to generate code that works incorrectly, and it won't warn you. The responsibility is entirely on you, the programmer.

Applying restrict to Function Parameters

The most common and impactful use of restrict is in function parameter lists. This makes the non-aliasing requirement part of the function's public API.

Let's modify our vector_add function:

void vector_add(int n, int *restrict result, const int *restrict a, const int *restrict b) {
    for (int i = 0; i < n; i++) {
        result[i] = a[i] + b[i];
    }
}

By adding restrict, we are now contractually obligated to call this function with non-overlapping memory buffers for result, a, and b. In return, the compiler can generate highly optimized code, knowing that a write to result cannot possibly affect the data read from a or b.

A classic example is the standard library function memcpy. Its C99 prototype is:
void *memcpy(void *restrict s1, const void *restrict s2, size_t n);

This is why memcpy's behavior is undefined if the source and destination buffers overlap. The restrict keyword formalizes this requirement. The function that does allow overlapping buffers is memmove, and you'll notice its parameters are not restrict-qualified.

To see the real-world performance impact, let's examine a concrete example.

This example clearly demonstrates the power of restrict. By providing the compiler with more information, you enable it to restructure the code in a way that is much more efficient for modern CPUs, which is a key concern in high-throughput systems like ADAS data processing pipelines.

Practical Guidelines for Using restrict

While the concept is powerful, using it correctly requires care.

Key "Do's and Don'ts" to remember:

• Do understand you are making a promise that, if broken, leads to undefined behavior.
• Do make restrict part of your function's interface specification and documentation.
• Do focus on using restrict for function parameters and pointers dereferenced inside performance-critical loops.
• Don't hide restrict inside a typedef. Its visibility at the point of declaration is important for code clarity.
• Don't second-guess the compiler. Stick to the C standard's definition of restrict to ensure your code is portable and robust.

uint8_t my_frame[512];
uint8_t my_payload[492];

// Scenario 1
uint8_t* p_payload = my_payload;
const uint8_t* p_frame = my_frame;
uint32_t* p_footer = (uint32_t*)&my_frame[508];

process_frame(p_payload, p_frame, p_footer);

// Scenario 2
uint8_t* p_payload = &my_frame[16]; // Payload is part of the frame
const uint8_t* p_frame = my_frame;
uint32_t* p_footer = (uint32_t*)&my_frame[508];

process_frame(p_payload, p_frame, p_footer);

// Scenario 3
uint8_t* p_payload = &my_frame[8]; // payload_buf overlaps with header
const uint8_t* p_frame = my_frame;
uint32_t* p_footer = (uint32_t*)&my_frame[508];

process_frame(p_payload, p_frame, p_footer);

Conclusion

We have now added the final major C type qualifier to your toolkit. While const and volatile are about managing data properties (immutability and unpredictable change), restrict is about managing data access and eliminating aliasing to unlock performance.

Key Takeaways:

• restrict is a promise to the compiler that the memory accessed through a restrict-qualified pointer will not be accessed by any other pointer in the same scope.
• This promise allows the compiler to perform aggressive optimizations, such as instruction reordering, holding values in registers, and vectorization (SIMD).
• The most powerful application is on function parameters, where it becomes part of the function's API contract, clearly documenting the non-aliasing requirement.
• Violating the restrict contract leads to undefined behavior, making it a tool that requires programmer discipline.

Preview of the Next Lesson:
We've now covered const, volatile, and restrict in isolation. The next logical step is to see how they interact. In our next lesson, we will learn how to correctly combine multiple type qualifiers, such as const volatile int *, to precisely describe the properties of data and pointers in complex embedded systems.