llvm-project

LLVM devs are apparently still working on adding proper i386 support https://github.com/llvm/llvm-project/issues/58470 but if that were to be addressed, we might even be able to use clang or rustc to build proper DPMI-based code for DOS. That would then leave 8086 real mode and 80286 protected mode as the next steps - admittedly quite a bit harder, given the need to deal with the complexity of segmented memory and the related issue of "code models".

LLVM's implementation is here, more or less: https://github.com/llvm/llvm-project/blob/main/libc/src/stri...

AVR should be working these days https://github.com/llvm/llvm-project/tree/main/llvm/lib/Targ... Unless you mean some specific chips?

It also slightly annoys me a bit the things JIT people write on their github READMEs about the incredibly theoretical improvements that can happen at runtime, yet it's never anywhere close to AOT compilation. Then you can add 2-3x on top of that for hand-written assembly. I do wonder whats going on with projects like BOLT though. I have seen it was merged into LLVM, and I have tried to use it but the improvement was never more than 7%. I feel like it has a lot of potential because it does try to take run-time into account. See: https://github.com/llvm/llvm-project/tree/main/bolt

Yeah, I did a quick check in LLVM at some point to see what it does (query I relied on: https://github.com/llvm/llvm-project/search?q=getPredictable...) and all the results seemed to be exclusively code motion or deciding how to lower a branch. Similarly cold path outlining seemed to just want to split the function in a fairly simple manner rather than doing anything beyond that. Perhaps I missed something, but I think the current hints are just to help the branch predictor or instruction cache rather than significantly alter codegen. Unfortunately, I don't have much to share at the moment besides my thoughts; I've done a few small tests but haven't been able to really do a full implementation yet. The primary consumer of this work would be iSH (https://github.com/ish-app/ish), which has a need for a fast interpreter, so you can at least

The article references a few compiler extensions: __builtin_xnu_type_signature, __builtin_xnu_type_summary, and the xnu_usage_semantics attribute. I can see references to these builtins in the latest xnu source[1], but not in upstream llvm[2], or Apple's forks of llvm[3] and clang[4]. It's been possible to build your own XNU[5] for a long time. Is that still possible now? [1]: https://github.com/apple-oss-distributions/xnu [2]: https://github.com/llvm/llvm-project [3]: https://github.com/apple-oss-distributions/llvmCore [4]: https://github.com/apple-oss-distributions/clang [5]: https://kernelshaman.blogspot.com/2021/02/building-xnu-for-macos-112-intel-apple.html

Nether llvm nor clang are GPL, dual licensed or otherwise. They're Apache 2.0[1] (or formerly a quasi-MIT/X11 license[2]), as is swift[3]. The binaries of the compilers they release with the platform are also built with internal forks that have some differences with the public llvm/clang/swift trees and that wouldn't be possible with gpl. [1] https://github.com/llvm/llvm-project/blob/main/llvm/LICENSE.... [2] https://github.com/llvm/llvm-project/blob/7555c589af006c9c4d... [3] https://github.com/apple/swift/blob/main/LICENSE.txt

AArch64 supports accelerated SHA-3, available on production systems since 2019 with the Apple A13, judging by https://github.com/llvm/llvm-project/blob/c35ed40f4f1bd8afd7... Power10 also supports accelerated SHA-3: https://www.redbooks.ibm.com/redpapers/pdfs/redp5649.pdf (p150) Accelerated SHA-3 on x86_64 is probably an inevitability; the question is more when than if.

Ken Zadeck was my office mate at IBM Research for a bit, and told me these groups of people (Ron, etc and Mark/Kenny) essentially discovered they had solved each others problems (Ken/Mark needed a formalism and efficient computation, Ron, etc were looking to understand how to use this stuff more broadly) while wandering the halls of watson research and seeing a group of people whiteboarding something at the end of one of the halls. I"m sure it's not quite that simple (and it's been over a decade, so i may be misremembering some details anyway), but still pretty funny. Also explained why the paper often feels like two papers - it kinda is. Nowadays, of course, plenty of linear time algorithms exist for this. In fact, there is basically a whole class of linear time transforms that, when applied to code, will reduce some group of polynomial

I wonder whether this project is based on the work in our M68k backend: > https://github.com/llvm/llvm-project/tree/main/llvm/lib/Targ...

Someone created a github issue for this: https://github.com/llvm/llvm-project/issues/56432

The canonical build system for LLVM is CMake, but you can also build LLVM with Bazel now. That might give you a good idea of how to do it. The Bazel support code is in https://github.com/llvm/llvm-project/tree/main/utils/bazel