9 ms·
LLVM 5.0.0 Release
- mhh__ 9y agoThose LLD benchmarks are looking very impressive! Well done to all involved.
- kibwen 9y agoWhere are you seeing the LLD benchmarks? I'm very curious about the prospect of LLD performance improvements for the benefit of the Rust compiler, and having benchmarks would be lovely.
- wyldfire 9y agoMaybe these [1] ones comparing ld, gold, lld? [1] https://lld.llvm.org/#performance https://lld.llvm.org/#performance
- 0x0 9y agoJust in time for Xcode 9? :)
- santaclaus 9y agoNow if only Apple would quit mysteriously stripping out features from the full LLVM release...
- bluejekyll 9y agoWhat are they stripping out?
- gcp 9y agoOpenMP, for one. They at least used to strip thread_local too.
- rleigh 9y agoWorking in scientific software development, I've seen quite a few people developing on Macs who would really appreciate OpenMP support. They end up having to use GCC or a vanilla Clang, but it's extra work and it comes with its own caveats.
- DannyBee 9y agoThey just don't ship the runtime library, no?
- Karliss 9y agoIt seems more likely that they simply don't use upstream release tags and put their changes and maybe backport some changes on top of randomly chosen revision. The same way as Google released Android ndk r15 few months ago with clang "5.0". The sad part is that their version is neither older or newer than official release as it doesn't contain everything from upstream release and upstream doesn't contain all of their changes yet.
- 0x0 9y agoIt can't possibly be pure coincidence that a major llvm release is timed about one week off from the annual major apple macOS/iOS/toolchain + iPhone hardware release, with their history of employing big llvm contributors?
- theresistor 9y agoIt is. The tool chain going into those releases is locked down months in advance.
- DannyBee 9y agoGiven the current release manager works for me at Google, probably not related :) I thought Swift still had parts of LLVM forked anyway, IIRC.
- mirekrusin 9y agoThis is the first time I can see Zig lang [1]. (Self-proclaimed?) C successor with manual memory management, ironed out edge cases, new take on error handling (that resembles well written error handling in C), generics, compile time reflection/execution (macros?), import .h works directly, exporting to C works directly, nullable types etc... all sound quite interesting actually. Anybody has experience/comments on the Zig lang, please? [1] http://ziglang.org/ http://ziglang.org/
- jandrese 9y agoInteresting. I've been somewhat disappointed with Rust thus far and this looks a lot more like what I was hoping for.
- kbenson 9y agoWhat did you find disappointing? What were you hoping for (so I can compare it to my own hopes)? Rust is the one (out of Rust, Nim and D) that looks most promising to me from the outside for my goals[1], but I haven't really settled on one to devote my very limited free time to. 1: If I'm going to drop down from a high level dynamic interpreted language to a low level strongly typed compiled one, I might as well got the extra distance Rust is asking for the gains it promises.
- jandrese 9y agoMostly I ran into a lot of friction with shared data structures that are being accessed by multiple threads. Stuff like ring buffers, flow state databases, and similar systems. There's probably Rust ways to do that stuff, but it was not obvious to me.
- littlestymaar 9y agoIf you're able to write a robust shared ring buffer in C, you should be able to do the exact same implementation in unsafe Rust using raw pointers, declare it as Sync and use it from safe Rust with no issue. Or am I missing something ? Or, if you're like me and not confident enough to do this, you could check on crates.io[1] to see if no available lib already does what you need. In which case you basically have it for free. [1] https://crates.io/keywords/ring-buffer https://crates.io/keywords/ring-buffer
- rui314 9y ago> ./configure scripts generated by GNU autoconf determines whether a linker supports modern GNU-compatible features or not by searching for "GNU" in the --help message. To be compatible with the scripts, we decided to add a string "(compatible with GNU linkers)" to our --help message. This is a hack, but just like the web browser's User-Agent string (which everyone still claim they are "Mozilla/5.0"), we had no choice other than doing this to claim that we accept GNU-compatible options. http://releases.llvm.org/5.0.0/tools/lld/docs/ReleaseNotes.html http://releases.llvm.org/5.0.0/tools/lld/docs/ReleaseNotes.h... Even though I wrote it, I found this part a bit funny. Configure scripts are hacky by their nature, and we needed another hack to make their hack work. I'm not happy about that though.
- chubot 9y agoYup, this is why feature detection is better than version detection. jQuery changed their strategy in 2009: http://blog.jquery.com/2009/01/14/jquery-1-3-released/ http://blog.jquery.com/2009/01/14/jquery-1-3-released/ "No More Browser Sniffing" Also, autoconf has a lot of faults, but as far as I recall it's firmly based on the philosophy of feature detectino vs. version detection. Maintainers of packages can write bad custom checks that test for features, but if you use the built-in autoconf checks, they're all about features. CMake on the other hand seems to use version detection more, which I don't like.
- wvenable 9y agoIt helps when you have a platform that supports feature detection reliably. Most platforms don't have that lucky accident.
- chubot 9y agoWhat's an example where of a feature of cc or ld that you can't detect with feature detection? Shell scripts are turing complete and can do arbitrary I/O. In theory you can write a feature detection for any feature by compiling, linking, and running a test program. If the feature couldn't be detected this way, then it would be useless. Likewise, JavaScript and DOM features should always be detectable by eval(). I guess one instance where it's impossible is if the API changes the pixels on the screen and does nothing else. Although you can actually detect this in some cases with JavaScript! JavaScript can leak information through the colors of attributes on the screen, e.g. you can tell if a user visited a site by looking if the link is purple!
- KenoFischer 9y agoOne feature I'm excited about in this release is proper support for non-integral address spaces. Allows us to do significantly more optimization in the presence of GC roots in Julia.
- pc2g4d 9y agoBetter AVR support for Rust? Can anyone comment on this?
- mhh__ 9y agoWell, the AVR backend is being actively developed, I have no idea how good it is. (Although some tooling for embedded systems is rather poor, so one would imagine that LLVM with the right heuristics couldn't do badly). rustc is apparently (https://github.com/rust-embedded/rfcs/issues/3 https://github.com/rust-embedded/rfcs/issues/3) not far of it being usable. However, I don't regularly write code for uC-ers - and when I do, it's usually simple enough to be in assembly - so I can't really say anymore than that.
- dyl 9y agoAVR-Rust author here The backend itself is working very well - there are only a handful of known bugs at this point, and many projects can be compiled with no issues. The issue you linked also links to (https://github.com/rust-lang/rust/issues/44052 https://github.com/rust-lang/rust/issues/44052), which shows that once these bugs are fixed, we can start working on merging avr-rust upstream. A number of projects/libraries have also been developed recently * https://github.com/avr-rust/blink https://github.com/avr-rust/blink * https://github.com/avr-rust/avrd https://github.com/avr-rust/avrd * https://github.com/avr-rust/arduino https://github.com/avr-rust/arduino * https://github.com/gergoerdi/rust-avr-chip8-avr https://github.com/gergoerdi/rust-avr-chip8-avr
- hawski 9y agoDoes anyone know the state of the project to compile Linux Kernel with clang? Does this release help with such a goal?
- wyldfire 9y agoI don't recall seeing much recent activity on the mailing lists along these lines. I have a very vague recollection that Linux may be dependent on gcc specific features that clang doesn't intend to support? EDIT: "One of the major compilation problems with LLVM/CLang is that they do not support VLA’s ... widely used inside the linux kernel." from [1] There was some activity over the prior six months or so to get lld to link the kernel (can't recall if it was built by gcc or clang for those tests). [1] https://www.quora.com/What-is-the-state-of-the-art-of-compiling-the-Linux-Kernel-using-LLVM-Clang https://www.quora.com/What-is-the-state-of-the-art-of-compil...
- rmusial 9y agoFrom an August 23 email ( https://lists.linuxfoundation.org/pipermail/llvmlinux/2017-August/001517.html https://lists.linuxfoundation.org/pipermail/llvmlinux/2017-A... ) Over the past months efforts have been made to upstream the remaining LLVMLinux patches (http://llvm.linuxfoundation.org http://llvm.linuxfoundation.org) and to address other outstanding issues in order to build a usable kernel with clang. To my knowledge upstream is in a relatively good shape by now for x86 and arm64 (I heard the same about PowerPC, but have no first hand experience), most of the patches are already in Linus' tree, others have landed in maintainer trees. ... It goes on, but there has been some pretty significant work done, and you can easily compile with clang as your default cc with simple patches.
- kccqzy 9y ago> Added heuristics to convert CMOV into branches when it may be profitable Does anyone know why this is the case? I thought CMOVs are a straight win over branches but I guess modern CPUs might be more complicated than that.
- kraghen 9y agoCMOV introduces a data dependency. Predictable branches, on the other hand, are basically free.
- matt_d 9y ago"LLVM compiler recognizes opportunities to transform a branch into IR select instruction(s) - later it will be lowered into X86::CMOV instruction, assuming no other optimization eliminated the SelectInst. However, it is not always profitable to emit X86::CMOV instruction. For example, branch is preferable over an X86::CMOV instruction when: - Branch is well predicted - Condition operand is expensive, compared to True-value and the False-value operands" https://reviews.llvm.org/D34769 https://reviews.llvm.org/D34769 "We have seen periodically performance problems with cmov where one operand comes from memory. On modern x86 processors with strong branch predictors and speculative execution, this tends to be much better done with a branch than cmov. We routinely see cmov stalling while the load is completed rather than continuing, and if there are subsequent branches, they cannot be speculated in turn." https://reviews.llvm.org/D36858 https://reviews.llvm.org/D36858
- gnuvince 9y agoWhat's a good reference to get started with LLVM? I've been wanting to write an Oberon-2 compiler, but I don't know what LLVM provides, nor how I might use it from Rust.
- SolarNet 9y agoIt provides IR, low level optimization passes, native code generation, and common metadata features (e.g. for debugging). Rust probably has a library somewhere that binds to it. So you would have to write linking (with help from LLVM), ASTs, high-level optimizations and validation, garbage collection (with help from LLVM), and standard library (or link an existing one). Also intermediate IRs or ASTs you plan on using (for example Rust's MIR) and their infrastructure.
- gcp 9y agoAdded support for AMD Lightweight Profiling (LWP) instructions. Funnily enough, AMD already deprecated those. They're not in Zen.