It's quite complicated. Sometimes hardware instructions are awkward or redundant enough that compilers ignore them. Or they're broken in hardware and the compil

It's quite complicated. Sometimes hardware instructions are awkward or redundant enough that compilers ignore them. Or they're broken in hardware and the compiler tries to patch around them. Sometimes there are invariants that are easy for compilers and really annoying for assembly programmers. A given sequence of instructions may execute correctly on multiple (sub)architectures with widely divergent performance behaviour. The one binary that does minimal to no self modification on boot is popular with users but intrinsically slower. Arm's variable length vector instructions are catering to that. One binary that is specialised to hardware and expected arguments is the fastest you can do without optimising while the program is starting/running. However hardware usually changes slower than software. Specifically if a program starts running on a specific x64 chip it's likely to stay on that chip until it finishes running. Linux used to patch itself on boot to pick a faster memcpy (may still do). It seems obvious that fastest for sufficiently long running processes is to ship a compiler IR, specialise first to the hardware and second to patterns in the data. OpenCL/spir-v have a finaliser premise where you lower to a given GPU just before running on it. Specialising on program data is branded JIT compilation. I don't know of anything doing both yet.