ml-compiler-opt VS llvm-project

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 use interpretable models like decision trees), but something like a neural network works fundamentally differently than the existing heuristics, so you probably wouldn't see most of the performance gains. For just tuning heuristics, the usual practice is to make most of the parameters configurable and then use something like bayesian optimization to try and find an optimal set, and this is sometimes done as a baseline in pieces of ML-in-compiler research.

1. https://github.com/google/ml-compiler-opt/pull/109

If you're using Clang/LLVM you can also enable ML inlining[1] (assuming you build from source) which can save up to around 7% if all goes well.

There are also talks of work on just brute forcing the inlining for size problem for embedded releases for smallish applications. It's definitely feasible if the problem is important enough to you to throw some compute at it [2].

1. https://github.com/google/ml-compiler-opt

2. https://doi.org/10.1145/3503222.3507744

LLVM's inlining-for-size and register-allocation-for-performance optimizations are both implemented using machine learning models trained by Google.

Continue reading | Checkout the paper, github, demo and ref article.

Looks like they do have a pretrained model:

https://github.com/google/ml-compiler-opt/releases/download/...

The code will by default auto-download it during the build process. It's about 800 kbytes, which seems very reasonable for something that will reduce the generated code size by gigabytes for a large codebase.

LLD has a new option "--randomize-section-padding" for this purpose: https://github.com/llvm/llvm-project/pull/117653

Github issue:

https://github.com/llvm/llvm-project/issues/127365

The article is right: it is almost never a compiler bug. I have had that experience of reporting and being wrong. It sucks.

On the other hand, I have a confirmed bug in Cland [1] and a non-rejected bug in GCC [2], so it does happen.

[1]: https://github.com/llvm/llvm-project/issues/61133

[2]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448

Have been is the right word.

This thread keeps having its goal posts moved around, first is was an example, then got the spotlight of being only about clang, then I pointed out about Apple/Google original purposes, then it was something else, and yet another one.

Just head off to /r/cpp that is where hunches are coming from.

Have you at very least filtered by C++ clang only related contributions instead of LLVM ones?

Most likely not, only clicked here https://github.com/llvm/llvm-project/graphs/contributors and came right away to reply.

I'm excited about -fbounds-safety coming soon: https://github.com/llvm/llvm-project/commit/64360899c76c

okay can you at least tell me how the architecture of https://github.com/llvm/llvm-project is "bad"?

https://github.com/llvm/llvm-project/blob/main/clang/docs/Bo...

Incidentally, this automatic branch-if-zero from LLVM is being improved.

First of all, a recent LLVM patch apparently changes codegen to use CMOV instead of a branch:

https://github.com/llvm/llvm-project/pull/102885

Beyond that, Intel recently updated their manual to retroactively define the behavior of BSR/BSF on zero inputs: it leaves the destination register unmodified. This matches the AMD manual, and I suspect it matches the behavior of all existing x86-64 processors (but that will need to be tested, I guess).

If so, you don't need either a branch or CMOV. Just set the register to 32 and then run BSR. If the value is zero, then BSR leaves the register unmodified and you get 32.

Since this behavior is now guaranteed for future x86-64 processors, and assuming it is indeed compatible with all existing x86-64 processors, LLVM will no longer need the old path regardless of what it's compiling for.

Note that if you're targeting a newer x86-64 version, LLVM will just emit TZCNT, which just does what you'd expect and returns 32 if the input is zero (or 64 for a 64-bit TZCNT). But as the blog post demonstrates, many people still build for baseline x86_64.

(Intel does document one discrepancy between processors: "On some older processors, use of a 32-bit operand size may clear the upper 32 bits of a 64-bit destination while leaving the lower 32 bits unmodified.")