Hacker News Reader

Comment by wyldfire | Hacker News Reader

> 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.

View on HN

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.

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.

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

> 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.

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.

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

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.

Reply on news.ycombinator.com