arya dradjicaI'm a little surprised that Rust/LLVM doesn't optimize away certain atomic operations. See https://play.rust-lang.org/?version=stable&mode=release&edition=2024&gist=c9f0f10929e66817a7df54775eb46f52 (compile to assembly in release mode); an unused atomic load (with Relaxed or Acquire ordering) won't be elided, and an atomic swap with unused loaded value won't be downgraded to a store. I'm fairly confident that the atomic loads can be elided, but I'm willing to believe that the downgrading the RMW swap operation might affect e.g. release-acquire sequences. Perhaps these atomic operations are so rare (and usually, hopefully, done properly) that optimizing them is not worthwhile?
Ramkumar Ramachandra@pinskia @wren6991 One of the things that really annoyed me when I was contributing to git as a hobby were the merge windows: I would often get the idea and motivation for a patch close to a release, but I'd have to shelve it until after the release! A simple release branch, with manual cherry-picks from main, like in #LLVM would be sufficient.
Releases are pretty inconsequential for developers, as they're always running on main anyway.
Ray KelmI spent a few hours getting a compiler toolchain set up for building #c64
programs. I tried #calypsi and #llvm, and so far llvm-mos generates much more compact code. I also tried using the rustc, compiling to llvm intermediate, then compiling that to 6502. The resulting binary didn’t quite work, so I’m going to build a custom rustc and try that. The code it generated was highly optimized. Using the same backend, #rust generated larger code than C, but it was aggressively optimized for speed instead of size.
For example, when copying sprite data from a const array it generated a lot of STA ops using the same values stored in registers, since the data was highly repetitive. The same code in C copied a const array using a loop. If I had to guess, the Rust code was much faster, and might be a couple bytes longer. For the entire program, the same code written in C was a couple hundred bytes smaller (like 500 vs 700 or so). Once it actually works, I’m going to do a deeper dive on the generated code.
Preparatory step in fixing long-standing miscompiles stemming from lack of per-use wrap flags in #LLVM ScalarEvolution just landed! A major design flaw in ScalarEvolution is fixed, yay! 🎉
[SCEV] Introduce SCEVUse, use it instead of const SCEV * (NFCI). by fhahn · Pull Request #91961 · llvm/llvm-project
This patch introduces SCEVUse, which is a tagged pointer containing the used const SCEV *, plus extra bits to store NUW/NSW flags that are only valid at the specific use. This was suggested by @nik...
Lens
Curated Hacker NewsEmacs internals: Tagged pointers vs. C++ std:variant and LLVM (Part 3)
Major #LLVM LoopVectorize patch just dropped, promising to clean up a lot of convoluted legacy code!
[LV] Simplify and unify resume value handling for epilogue vec. by fhahn · Pull Request #185969 · llvm/llvm-project
This patch tries to drastically simplify resume value handling for the scalar loop when vectorizing the epilogue. It uses a simpler, uniform approach for updating all resume values in the scalar lo...
Zenn Trends📰 LLVMに対する32ビット定数除算の改善 (👍 33)
🇬🇧 PR merged to LLVM improving 32-bit unsigned constant division optimization using 33-bit magic constants on 64-bit targets.
🇰🇷 64비트 타겟에서 33비트 매직 상수를 사용한 32비트 부호 없는 상수 나눗셈 최적화 개선 PR이 LLVM에 병합됨.
📰 LLVMに対する32ビット定数除算の改善 (👍 28)
🇬🇧 LLVM optimization PR merged: improves 32-bit constant division using 33-bit magic constants on 64-bit targets, benefiting C/C++/Rust/Swift compilers.
🇰🇷 LLVM 최적화 개선: 64비트 타겟에서 33비트 매직 상수를 사용한 32비트 정수 나눗셈 최적화. C/C++/Rust/Swift 등에 적용.
📰 LLVMに対する32ビット定数除算の改善 (👍 24)
🇬🇧 LLVM optimization improvement for 32-bit constant division merged to main - benefits C/C++/Rust/Swift compilers using 33-bit magic constants
🇰🇷 32비트 상수 나눗셈에 대한 LLVM 최적화 개선이 메인에 병합 - 33비트 매직 상수를 사용해 C/C++/Rust/Swift 컴파일러에 이점