What a Backend Must Know About Its Target

A backend is parameterised by four things, and getting any of them wrong produces a different class of bug. The instruction set says what operations exist and in what operand shapes — whether arithmetic is two- or three-operand, whether there is a fused multiply-add, whether unaligned loads work. The register file says how many registers there are, what classes they fall into, and how they alias — on x86-64 eax is the low half of rax and writing it zeroes the top, which is a fact the allocator must model.

The calling convention says where arguments and returns live and which registers survive a call. And the memory model says which reorderings of memory operations the hardware may perform, which bounds what the compiler may do on top — see [[memory-model]] in the concurrency domain for the hardware and language halves.

Notice that only the first is what people usually mean by "the architecture". The other three are why the same ISA with a different ABI is effectively a different target, and why x86_64-pc-windows-msvc and x86_64-unknown-linux-gnu need different backend configuration despite being the same instruction set — the subject of [[target-triples]].

Three of the four targets above are machines. WebAssembly is not: it is a portable compilation target with a stack machine, structured control flow, no registers and no addresses in the usual sense. Backing it changes what a backend even means.

Register allocation, the subject of an entire module of this domain, does not exist — values live on an operand stack or in indexed locals, and the consumer of the wasm will do its own allocation when it compiles to the real machine. Instruction scheduling does not exist for the same reason. What replaces them is a problem no native backend has: wasm control flow is *structured*, made of blocks, loops and ifs rather than arbitrary jumps, so an arbitrary CFG must be converted back into nested structure — the relooper problem — and irreducible control flow may need node duplication to express at all.

This is the general shape of targeting a virtual ISA. You give up the machine-specific decisions and inherit a different set of constraints from the abstraction, and you defer the real backend work to whoever consumes your output — see [[wasm-vs-native]].

Naming an architecture is not enough. "x86-64" spans two decades of CPUs with wildly different feature sets — a binary using AVX-512 runs on some server parts and faults on most desktops; one using SSE2 runs everywhere. So a target is really an architecture plus a *subtarget*: a feature set and a tuning model.

Those two are separable and it is worth being precise about the difference. -march= (or -mcpu= on ARM) says which instructions the compiler may emit, and getting it wrong produces an illegal-instruction crash on the machines that lack them. -mtune= says which microarchitecture to optimise the scheduling and cost models for, and getting it wrong produces code that is merely somewhat slower. The first is a correctness setting; the second is a performance setting, and conflating them is how "it works on my machine" becomes a production incident.

The -march=native habit deserves particular suspicion in any build that ships anywhere but the build machine. It means "use everything this CPU has", which is exactly the wrong answer for an artefact that will run on a fleet. The usual production answer is a conservative baseline plus run-time dispatch: compile several versions of the hot function and select at startup based on CPU feature detection, which is what mainstream numerical libraries do.