24 ms·

> understanding. We evaluate on a large suite of test programs. Our approach achieves a 3.0% improvement in reducing instruction counts over the compiler, 3% c

> understanding. We evaluate on a large suite of test programs. Our approach achieves a 3.0% improvement in reducing instruction counts over the compiler, 3% code size reduction is really good. The challenge will be having codegen like this that someone is willing to support. And for that they'd want to be able to reason about why the compiler made this decision or that one. IIUC that's an outstanding problem for AI in general.

TheLoafOfBread 3y ago
Also bugs from this approach are going to be funny - program compiled with compiler version X will work as expected and same program compiled with version X+1 will start crashing because AI under some circumstances decided that dereference of a specific pointer was unnecessary, so it won't drop it into the assembly. Good luck finding such a bug, because you will be looking on correct code, but computer will be executing invalid output.
- a_wild_dandan 3y ago
  Damn. These things imitate humans too well. Guess we’ll need a giant test suite to feel stable. Sounds like work. Let’s train a GAN for that and put our feet up. Turtles all the way down, my dudes.
- boomanaiden154 3y ago
  The focus of this work is finding the optimal ordering of optimization passes to perform, not doing neural compilation. This guarantees correct code, assuming the underlying transformation passes are correct. Most work in ML for compilers focuses on replacing heuristics and phase ordering precisely because they don't impact correctness. There is some work being done on neural compilation [1], but I'm not sure that's going to be a viable approach anytime soon. 1. https://ieeexplore.ieee.org/document/9926313 https://ieeexplore.ieee.org/document/9926313
  - wyldfire 3y ago
    > phase ordering precisely because they don't impact correctness. lol let's say they're less likely to impact correctness than an arbitrary new optimization.
    - ncruces 3y ago
      If you find a bug, it's in the optimization passes (that don't reorder and should, if you decide to do this). At this point this is like (usefully) fuzzing your optimizer, which long term is going to be great for correctness.
JonChesterfield 3y ago
3% code size reduction while changing semantics is borderline worthless*. 3% code size reduction without changing semantics would be more interesting but might still be a bad thing for performance. *fast-math etc is a thing, where similar-enough output is fine
- cec 3y ago
  Hey Jon, we don't change semantics. We just choose optimization passes to run to match a particular input code. Agreed that code size wins could regress performance. We don't measure that yet, but will be looking into it next. There are some applications where codesize above-all-else is what to optimize for.

TheLoafOfBread 3y ago

Also bugs from this approach are going to be funny - program compiled with compiler version X will work as expected and same program compiled with version X+1 will start crashing because AI under some circumstances decided that dereference of a specific pointer was unnecessary, so it won't drop it into the assembly. Good luck finding such a bug, because you will be looking on correct code, but computer will be executing invalid output.

a_wild_dandan 3y ago
Damn. These things imitate humans too well. Guess we’ll need a giant test suite to feel stable. Sounds like work. Let’s train a GAN for that and put our feet up. Turtles all the way down, my dudes.
boomanaiden154 3y ago
The focus of this work is finding the optimal ordering of optimization passes to perform, not doing neural compilation. This guarantees correct code, assuming the underlying transformation passes are correct. Most work in ML for compilers focuses on replacing heuristics and phase ordering precisely because they don't impact correctness. There is some work being done on neural compilation [1], but I'm not sure that's going to be a viable approach anytime soon. 1. https://ieeexplore.ieee.org/document/9926313 https://ieeexplore.ieee.org/document/9926313
- wyldfire 3y ago
  > phase ordering precisely because they don't impact correctness. lol let's say they're less likely to impact correctness than an arbitrary new optimization.
  - ncruces 3y ago
    If you find a bug, it's in the optimization passes (that don't reorder and should, if you decide to do this). At this point this is like (usefully) fuzzing your optimizer, which long term is going to be great for correctness.

JonChesterfield 3y ago

3% code size reduction while changing semantics is borderline worthless*. 3% code size reduction without changing semantics would be more interesting but might still be a bad thing for performance. *fast-math etc is a thing, where similar-enough output is fine

cec 3y ago
Hey Jon, we don't change semantics. We just choose optimization passes to run to match a particular input code. Agreed that code size wins could regress performance. We don't measure that yet, but will be looking into it next. There are some applications where codesize above-all-else is what to optimize for.