mshockwave

one of the reasons I rarely read press releases is that I don't believe in promises -- I believe in _incentives_. In this case, what will Qualcomm be incentivized to do? What are in their interests?

indeed, open sourcing is only half (or even less) of the picture: who is driving the open source community and how it is driven (i.e. governing structure) are probably more important IMHO. There are countless of cases where an open source project is either killed by slow death, or dictated by a single entity. Chris's previous projects like LLVM and MLIR are fortunate enough to grow and thrive organically, and that takes years if not decades to cultivate

it's a book excerpt

Does gcc use LLVM anywhere under the hood

No

One thing I observed is that RVV code is usually slower in QEMU

LLVM now has another way to implement RTTI using the `CastInfo` trait instead of `classof`: https://llvm.org/doxygen/structllvm_1_1CastInfo.html

But it's really just an implementation difference, the idea is still to have a lightweight RTTI.

how did it do regalloc before instruction selection? How do you select the correct register class without knowing which instruction you're gonna use?

I don’t know many good reasons for extrusive linked lists

for one, its iterator won't be invalidated

Is it normal to spend 10minutes on tuning nowadays? Do we need to spend another 10 minutes upon changing the code?

It's likely that Swift compiler is using LLVM LIT (https://llvm.org/docs/CommandGuide/lit.html), which is implemented in python, as the test driver

In the end, programs will want probably to stay conservative and will implement only the core ISA

Unlikely, as pointed out in sibling comments the core ISA is too limited. What might prevail is profiles, specifically profiles for application processors like RVA22U64 and RVA23U64, which the latter one makes a lot more sense IMHO.

yes, it has been done for at least a decade if not more

Even more of a wild idea is to pair up two cores and have them work together this way

I don't think that'll be profitable, because...

When you have a core that would have been idle anyway

...you'll just schedule in another process. Modern OS rarely runs short on available tasks to run

The article is easy to follow but I think the author missed the e point: branchless programming (a subset of the more known constant time programming) is almost exclusively used in cryptography only nowadays. As shown by the benchmarks in the article, modern branch predictors can easily achieve over 95% if not 99% precision since like a decade ago

yes, the short answer is LLVM uses RegPressureTracker (https://llvm.org/doxygen/classllvm_1_1RegPressureTracker.htm...) to do all those calculations. Slightly longer answer: I should probably be a little more specific that in most cases, Machine Scheduler cares more about register pressure _delta_ caused by a single instruction, either traverses from bottom-up or top-down. In which case it's easier to make an estimation when some of other instructions are not scheduled yet.

The scenario suitable for TBM is surprisingly limited so even nowadays many tunnels are still dig using the good’o way, mostly with explosives

Came to say Apple also did a great job on tagging my bois who are both grey-ish cats, even in pictures they faced backward, no idea how they did that

I thought the original comment meant “_for_ who doesn’t use X or Discord, here is the github mirror link”. There’s a “for” missing, and thus I think they agree with you

second this, it didn't show anything when I hovered over North America

and grep / ripgrep. Or did ripgrep migrate to using io_uring already?

tangent: I believe Air Force and Navy have loosen the vision requirement quite a bit. IIRC the new rule only measures the corrected vision, regardless how you corrected it, including wearing glasses.

RVV is the hardest though (20k intrinsics)

A bit late to this comment but most of these intrinsics are overloads of different LMUL and SEW on a single instruction. I'm pretty sure the actual number of RVV instructions is way less. So maybe you could consolidate overloads of the same instruction into the same page or something.

This is pretty useful! Any plan for adding ARM SVE and RISC-V V extension?

that modeling instruction scheduling doesn't matter all that much for codegen on OoO cores.

yeah scheduling quality usually has a weaker connection to the performance of OoO cores. Though I would also like to point out:

  1. in-order cores still heavily relies on scheduling quality
  2. Issue width is actually a big thing in MachineScheduler regardless of in-order or out-of-order cores. So the problem you outlined above w.r.t different implementations of uops cracking is indeed quite relevant
  3. MachineScheduler does not use the BufferSize -- which more or less mirrors the issue queue size of each pipe -- at all for out-of-order core. MicroOpBufferSize, which models the unified reservation station / ROB size, only got used in a really specific place. However, these parameters matter (much) more for llvm-mca

This means I can't feed any function as-is (even a tiny one). I need to manually cut out the loop body.

It doesn't support branches at all. I know it's a very hard problem, but that's the problem I have

Shameless self-plug: https://github.com/securesystemslab/LLVM-MCA-Daemon

It was later reverted[1] because "there are devices in the field using usbX interfaces for tethering". Shortly after that, it got re-landed but only supported Android V+[2]

[1] https://android-review.googlesource.com/c/platform/packages/...

[2] https://android-review.googlesource.com/c/platform/packages/...

Nitpick: static link won’t give you inlining but only eliminates the overhead of PLT. LTO will give you more opportunities for inlining

In the case where one of the structs has just been computed, attempting to load it as a single 32-bit load can result in a store forwarding failure

It actually depends on the uArch, Apple silicon doesn't seem to have this restriction: https://news.ycombinator.com/item?id=43888005

In a non-inlined, non-PGO scenario the compiler doesn't have enough information to tell whether the optimization is suitable.

I guess you're talking about stores and load across function boundaries?

Trivia: X86 LLVM creates a whole Pass just to prevent this partial-store-to-load issue on Intel CPUs: https://github.com/llvm/llvm-project/blob/main/llvm/lib/Targ...

sometimes also known as superoptimization, which many of them also use SMT solvers like Z3 mentioned in the article

I might be wrong, but it seems like Anubis asks the _client_ to solve the cryptography challenges while the approach Cloudflare described here asks the server to verify the (cryptography) signature?

in addition to storing profiles, what about caching some native code? so that we can eliminate the JIT overhead for hot functions

EDIT: they describe this in their "Alternative" section as future work