3 ms·

This is very impressive! This is a risky bet for actual production use. There is no way you can 100% be sure that the generated binary is correct and matching

by msoad 2y ago

This is very impressive! This is a risky bet for actual production use. There is no way you can 100% be sure that the generated binary is correct and matching behavior with the original binary. There are cases that don't have unit tests and static analysis and formal verification can't be enough. Imagine a bug introduced by this that you have no idea where to begin to debug. I guess the best solution is to add a unit test and generate another binary with this system but do we really want to do this?

jhj 2y ago
A less risky use is to use the model to choose compilation flags and pass orderings many (but not all) of which (in theory) should always be correct but that's more of a problem of the compiler itself than of the model if it produces incorrect output, in order to replace auto-tuners that do the same in order to optimize production binaries. Large companies already use such auto-tuners anyways for widely used public or internal binaries (e.g., code size is a huge problem for mobile application builds that you are delivering to a billion people, and the pieces of code that you care about for code size compression you are doing so explicitly because they are not of serious performance concern (e.g., you don't need unrolled loops or whatever); it's not the entire binary to which you are doing this). Such flags/pass ordering options for binary optimization are already an exponentially huge search space. To use something for this for IR rewriting directly by the model is certainly more risky (it's difficult to guarantee post-rewrite that you would be computing the same thing; at least for compiler passes and optimization options, many of which also perform IR rewrites, the compiler such as LLVM/gcc should already have a huge suite of test coverage anyways). (I'm not a compiler person but I'm a researcher on the same team at Meta FAIR as the authors)

by msoad 2y ago

jhj 2y ago

A less risky use is to use the model to choose compilation flags and pass orderings many (but not all) of which (in theory) should always be correct but that's more of a problem of the compiler itself than of the model if it produces incorrect output, in order to replace auto-tuners that do the same in order to optimize production binaries. Large companies already use such auto-tuners anyways for widely used public or internal binaries (e.g., code size is a huge problem for mobile application builds that you are delivering to a billion people, and the pieces of code that you care about for code size compression you are doing so explicitly because they are not of serious performance concern (e.g., you don't need unrolled loops or whatever); it's not the entire binary to which you are doing this). Such flags/pass ordering options for binary optimization are already an exponentially huge search space. To use something for this for IR rewriting directly by the model is certainly more risky (it's difficult to guarantee post-rewrite that you would be computing the same thing; at least for compiler passes and optimization options, many of which also perform IR rewrites, the compiler such as LLVM/gcc should already have a huge suite of test coverage anyways). (I'm not a compiler person but I'm a researcher on the same team at Meta FAIR as the authors)