Optimizing that way simply hasn’t been common in a while.
Instead, the CPU vendor offers instruction extensions for particularly heavy yet common computations, and different levels of code try to take advantage of them where available: ideally by least likely, at the compiler level (“this looks like an implementation of SHA-1, but the CPU has an optimized one built in, so I’ll use that; often at the framework/library level (“you’re calling macOS’s SHA-1 function; on this modern CPU, it simply uses the built in CPU implementation”); and only in the worst case, in your own code (“I heard Skylake added some SHA-1 instructions; let’s use those when available“).
Even in that last case, you probably don’t need the CPU vendor’s help. And other CPU often eventually catch up with similar instructions. More likely, you’ll wait for the library you’re using (because you l shouldn’t be implementing SHA-1 yourself anyway) to catch up and do that work for you, likely in higher quality because it’s more likely to be battle-tested (the more people use the library, the less likely common bugs stick around, whereas the only consumer of your own code is going to be yourself).
What you’re imagining here is the 1990s’ way where you take entire sections of code in C that are suddenly inline assembler. You can do that, and you’ll have to do it for each arch, but it’s no longer common because of diminishing returns these days.
