5 ms·
It's not that people do better than compilers, it's just compilers often do badly. That's why checking disassembly in tight spots is the integral procedure in o
by okaleniuk 6y ago
It's not that people do better than compilers, it's just compilers often do badly. That's why checking disassembly in tight spots is the integral procedure in our team. Compilers and people together by definition do not worse than compilers alone.
Also, this is an odd choice of program to compare. Compilers often do suboptimal on superscalarisation, inlining, or simplifying control flow. In this example, there is not enough space to go wrong nor for a compiler neither for a programmer.
- gnufx 6y agoIsn't the first thing to do looking at what the compiler can tell you (-fopt-info for GCC)? That can be helpful without deep knowledge of the target, or knowing its assembler. There are also dumps from stages before generating assembly which may be helpful. Is it deep knowledge of the whole system that makes going straight to assembly best?
- okaleniuk 6y agoYes, GCC intermediates are quite nice. Lispy and readable. And indeed, you can take a look at every stage. But LLVM intermediate code is basically just another assembly language. And as for MSVC, I'm not sure if it's even accessible. So it's not always an option. Disassembly is either way our end result so unless you're looking for something particular, it makes sense to browse that first just to check that the compiler gets your intention just right.