> Have things improved since this article was written? Yes. > Are intrinsics best avoided? No. --- If you are writing assembly code by hand, you probably

> Have things improved since this article was written? Yes. > Are intrinsics best avoided? No. --- If you are writing assembly code by hand, you probably care about the quality of the generated code. Intrinsics are lower effort, portable, and can and often do generate much better code than using inline assembly. I disagree with the claim that verifying the assembly output of an intrinsics is more work than writing assembly code by hand. In my experience, it is significantly less work. I also disagree with the post about what to do if an intrinsic doesn't generate good code. "Tweak the intrinsic until you get a reasonable result" is probably the worst thing you can do, because once the intrinsic is fixed, your tweaks might prevent it from generating good code. The two things you can and should do are: - report the bug, so that it gets fixed (1-2 days for clang.. fixing an intrinsic is just adding a new "case" in a pattern matching table, writing down what instructions it should lower too... worst case you can fix this yourself if you know what it should lower to...), - if you can't live with worse code till the next compiler release, use inline assembly. This second point is super rare. Its just not worth it. Intrinsics are usually fixed in a couple of days if you report the bug, and the fixed intrinsic will be in the next compiler release in a couple of months if you can't use the nightlies. So unless you really need this now, this is often not worth doing.