TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Integrated assembler improvements in LLVM 19

104 点作者 MaskRay11 个月前

4 条评论

aengelke11 个月前
Nice summary! Additional changes I have planned:<p>- Removing per-instruction timers, which add a measurable overhead even when disabled (<a href="https:&#x2F;&#x2F;github.com&#x2F;llvm&#x2F;llvm-project&#x2F;pull&#x2F;97046">https:&#x2F;&#x2F;github.com&#x2F;llvm&#x2F;llvm-project&#x2F;pull&#x2F;97046</a>)<p>- Splitting AsmPrinterHandler (used for unwind info) and DebugHandler (used also for per-instruction location information) to avoid two virtual function calls per instruction (<a href="https:&#x2F;&#x2F;github.com&#x2F;llvm&#x2F;llvm-project&#x2F;pull&#x2F;96785">https:&#x2F;&#x2F;github.com&#x2F;llvm&#x2F;llvm-project&#x2F;pull&#x2F;96785</a>)<p>- Remove several maps from ELFObjectWriter, including some std::map (changed locally, need to make PR)<p>- Faster section allocation, remove ELF &quot;mergeable section info&quot; hash maps (although this is called just ~40 times per object file, it is very measurable in JIT use cases when compiling many small objects) (planned)<p>- X86 encoding in general; this consumes quite some time and looks very inefficient -- having written my own x86 encoder, I&#x27;m confident that there&#x27;s a lot of improvement potential. (not started)<p>Some takeaways on a higher level -- most of these aren&#x27;t really surprising, but nonetheless are very frequent problems(&#x2F;patterns) in the LLVM code base:<p>- Maps&#x2F;hash maps&#x2F;sets are quite expensive when used frequently, and sometimes can be easily avoided, e.g., with a vector or, for pointer keys, a pointer dereference<p>- Virtual functions(&#x2F;abstraction) calls comes at a cost, especially when done frequently<p>- raw_svector_ostream is slow, because writes are virtual function calls and don&#x27;t get inlined (I previously replaced raw_svector_ostream with a SmallVector&amp;: <a href="https:&#x2F;&#x2F;reviews.llvm.org&#x2F;D145792" rel="nofollow">https:&#x2F;&#x2F;reviews.llvm.org&#x2F;D145792</a>)<p>- Frequent heap allocations are costly, especially with glibc&#x27;s malloc<p>- Many small inefficiencies add up (=&gt; many small improvements do, too)
评论 #40853933 未加载
Keyframe11 个月前
Side note, but I was looking for a pre-built binaries in releases of LLVM project. Specifically I was looking for clang+llvm releases for x86_64 linux (ubuntu preferably) in order to save some time (always had trouble compiling it) and to put it into my own `prefix` directory. It&#x27;s kind of wild to see aarch64, armv7, powerpc64, x86_64_windows.. but not something like this. I am aware of <a href="https:&#x2F;&#x2F;apt.llvm.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;apt.llvm.org&#x2F;</a> and its llvm.sh - but as I said, I&#x27;d prefer it to live in its own `prefix`. Anyone knows where else there might be pre-builts? There used to be something just like that for v17, like <a href="https:&#x2F;&#x2F;github.com&#x2F;llvm&#x2F;llvm-project&#x2F;releases&#x2F;download&#x2F;llvmorg-17.0.6&#x2F;clang+llvm-17.0.6-x86_64-linux-gnu-ubuntu-22.04.tar.xz">https:&#x2F;&#x2F;github.com&#x2F;llvm&#x2F;llvm-project&#x2F;releases&#x2F;download&#x2F;llvmo...</a>
评论 #40853816 未加载
评论 #40849059 未加载
mncharity11 个月前
In the first sentence, &quot;[Intro to the LLVM MC Project]&quot; was likely intended to be a link[1].<p>[1] <a href="https:&#x2F;&#x2F;blog.llvm.org&#x2F;2010&#x2F;04&#x2F;intro-to-llvm-mc-project.html" rel="nofollow">https:&#x2F;&#x2F;blog.llvm.org&#x2F;2010&#x2F;04&#x2F;intro-to-llvm-mc-project.html</a>
评论 #40853807 未加载
matrix_overload11 个月前
TLDR: building projects with Clang is now about 4% faster due to optimizations in the way it internally handles assembly.
评论 #40843196 未加载
评论 #40845515 未加载