Thanks for bringing up specialized optimization tools such as Halide. Recently there's been a proliferation of domain-specific languages targeting this automati

Thanks for bringing up specialized optimization tools such as Halide. Recently there's been a proliferation of domain-specific languages targeting this automatic optimization-from-intentions paradigm. While it's great for testing new ideas isolated from the complexity of modern day compiling suites (academic excursions), actually devoting your codebase to these tools is a huge burden for future maintainability, and eliminates the possibility of future improvements provided outside the small development effort of a single academic group. Many of the techniques given here (and elsewhere in the glut of DSLs) are quietly folded into mainstream C compilers within a short timeframe -- first as requiring explicit hints just like the DSLs, then secondly simplified to allow the compiler to automatically infer hints from well-structured code relying on transformation guarantees of standard C idioms. So if you stick with strict C and come to understand the implicit assumptions/guarantees the standard dictates while conveying structure in your code, in time the compiler suites will march forward in improvements that come with each update 'for free.' And most importantly, update your testing infrastructure to be formally verified each refactoring (such as with CBMC) so that there's no regression problems caused by compiler updates with free reign!