boomanaiden154

6 ms·

1.
by boomanaiden154 6mo ago
Found it. It was https://www.phoronix.com/news/Intel-Thin-Layout-Optimizer . It was open source, but has since been deprecated.
2.
by boomanaiden154 6mo ago
Propeller can’t really do many instruction level modifications due to how it works (constructs a layout file that then gets passed to the linker). BOLT could do this, but does not as far as I’m aware. Most of vectorization like this is also
3.
by boomanaiden154 6mo ago
I might be thinking of a different project then... I swore Intel had their own PLO tool, but I can only find https://github.com/clearlinux/distribution/issues/2996 .
4.
by boomanaiden154 6mo ago
Post link optimization (PLO) tools have been around for quite a while. In particular, Meta’s BOLT (fully upstream in LLVM) and Google’s Propeller (somewhat upstream in LLVM, but fully open source) have been around for 5+ years at this point
5.
LLVM AI Policy and Automatic Bazel Fixes(phoronix.com)
1 points by boomanaiden154 9mo ago|0 comments
6.
by boomanaiden154 11mo ago
Quite a few patches have landed. A couple features using this have already shipped in Apple’s downstream clang.
7.
by boomanaiden154 2y ago
You can make the synthetic benchmarks relatively accurate, it just takes effort. The compile-time hit and additional effort is often worth it for the extra couple percent for important applications. Performance is also pretty different on t
8.
by boomanaiden154 2y ago
I'm not sure where you're getting your information from. Chrome (and many other performance-critical workloads) is using instrumented PGO because it gives better performance gains, not because it's a more mature path. AutoFDO
9.
by boomanaiden154 2y ago
It's not called AutoFDO. AutoFDO refers to a specific sampling-based profile technique out of Google ( https://dl.acm.org/doi/abs/10.1145/2854038.2854044 ). Sometimes people will refer to that as PGO thoug
10.
by boomanaiden154 2y ago
Do you have more information on how the dataset was constructed? It seems like somehow build systems were invoked given the different targets present in the final version? Was it mostly C/C++ (if so, how did you resolve missing include
11.
by boomanaiden154 2y ago
I'm not sure it's likely that the LLM here learned from gcc. The size optimization work here is focused on learning phase orderings for LLVM passes/the LLVM pipeline, which wouldn't be at all applicable to gcc. Additiona
12.
by boomanaiden154 2y ago
This would be difficult to deploy as-is in production. There are correctness issues mentioned in the paper regarding adjusting phase orderings away from the well-trodden O0/O1/O2/O3/Os/Oz path. Their methodology wor
13.
by boomanaiden154 2y ago
Sure, performance is more interesting, but it's significantly harder. With code size, you just need to run the code through the compiler and you have a deterministic measurement for evaluation. Performance has no such metric. Benchmark
14.
by boomanaiden154 2y ago
I'm reasonably certain the authors are aware of alive2. The problem with using alive2 to verify LLM based compilation is that alive2 isn't really designed for that. It's an amazing tool for catching correctness issues in LLVM
15.
by boomanaiden154 2y ago
PGO can be used in such situations, but the profile needs to be checked in. Same code + same profile -> same binary (assuming the compiler is deterministic, which is tested quite extensively). There are several big projects that use PGO
16.
by boomanaiden154 2y ago
I would not say we are anywhere close to perfect in compilation. Even just looking at inlining for size, there are multiple recent studies showing ~10+% improvement ( https://dl.acm.org/doi/abs/10.1145/3503222.
17.
by boomanaiden154 2y ago
Right, it's only solving phase ordering. In practice though, correctness even over ordering of hand-written passes is difficult. Within the paper they describe a methodology to evaluate phase orderings against a small test set as a smo
18.
by boomanaiden154 3y ago
LLVM doesn’t spend really any runtime solving the phase ordering problem since the pass pipelines are static. There have been proposals to dynamically adjust the pipeline based on various factors, but those are a ways out from happening.
19.
by boomanaiden154 3y ago
Pretty much this. It's called Alive2. https://dl.acm.org/doi/abs/10.1145/3453483.3454030
20.
by boomanaiden154 3y ago
ML for phase ordering is just one problem that ML could solve within compilers. Heuristic replacement (like loop unrolling) is another big one. For the specific case of loop unrolling, I would think lower level elements like how much iCache
21.
by boomanaiden154 3y ago
What's the benefit of having an LLM do those things in a way that guesstimates? There are big wins to be had in code-size and some wins to be had in performance related to inlining [1][2], but I think the implementation in the referenc
22.
by boomanaiden154 3y ago
Most of the work in this space is not focused on neural compilation (having a ML model perform the transformation/entire compilation), but on replacing heuristics or phase ordering, where the issue of correctness falls back onto the co
23.
by boomanaiden154 3y ago
I did a bit of work on this last summer on (much) smaller models [1] and it was briefly discussed towards the end of last year's MLGO panel [2]. For heuristic replacements specifically, you might be able to glean some things (or just u
24.
by boomanaiden154 3y ago
You're right that a decrease in code size doesn't mean a performance increase (and oftentimes they can be inversely correlated like in inlining). But LLVM targets both depending upon what optimization pipeline you select. (-Oz&#x2
25.
by boomanaiden154 3y ago
I'm not sure a fully correct production optimizing compiler is that feasible. LLVM gets multiple miscompilation reports per week (from what I've haphazardly seen observing the issue tracker). Theoretically changing the order of t
26.
by boomanaiden154 3y ago
One of the biggest things that seems to be holding back ML in compilers right now is dataset size. This model was only trained on a gigabyte of source code, 30+% of that synthetic. Even on much simpler models, there have been massive perfor
27.
by boomanaiden154 3y ago
For function inlining specifically, I'm not sure LLMs are necessarily the right choice. The original MLGO paper [1] demonstrated a big code-size improvement with a ML model for making inlining decisions (7-20% code size wins), but they
28.
by 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 f
29.
by boomanaiden154 3y ago
There's already tooling available for using SMT to validate LLVM-IR transformations [1]. It's designed for zero false positives however, so some things might slip through the cracks. Additionally, this work focuses on phase orderi
30.
by boomanaiden154 3y ago
It's a workshop intended to facilitate discussion in the space. The lead author of this paper (Chris Cummins) will probably be there. https://discourse.llvm.org/t/pre-llvm-dev23-ml-guided-compil...

More ›