Aliasing

Summary

Aliasing Written by me, proof-read by an LLM. Details at end. Yesterday we ended on a bit of a downer: aliasing stopped optimisations dead in their tracks. I know this is supposed to be the Advent of Compiler Optimisations, not the Advent of Compiler Giving Up! Knowing why your compiler can’t optimise is just as important as knowing all the clever tricks it can pull off. Let’s take a simple example of a counter class. It accumulates integers into a member variable total. I’ve used C++ templates to show two versions of the code: one that accumulates in an int and one that accumulates in an long. At first glance, the two loop bodies look almost identical, as you might expect. In one case we’ll accumulate in eax, and the other in rax, right? The truth is more subtle. Let’s first look at the int case: mov eax, DWORD PTR [rdi] ; eax = total .L3: add eax, DWORD PTR [rsi] ; add element to total add rsi, 4 ; move to next element mov DWORD PTR [rdi], eax ; total = eax cmp rsi, rdx ; are we finished? jne .L3 ; loop if not ret Looks pretty reasonable, right? Now let’s look at the long version: mov rax, QWORD PTR [rdi] ; rax = total .L9: movsx rdx, DWORD PTR [rsi] ; read & sign extend next element add rsi, 4 ; move to next element add rax, rdx ; rax += element cmp rcx, rsi ; are we finished? jne .L9 ; loop if not mov QWORD PTR [rdi], rax ; total = rax ret ; return The first change from the 32-bit case you’ll notice is the movsx to turn the 32-bit signed integer into a 64-bit signed integer. That’s all but free on modern CPUs, and so while it looks like the loop is doing more work than the 32-bit version, it’s not as bad as it seems. The important difference here is the update of total: In the first version, each loop iteration updates the member variable total. In the second version everything remains in registers until the end of the loop, and then total is only updated at the end. CPU caches are super fast, but it’s still best to avoid redundant stores in hot loops! So, why t...