mshockwave

if every `=` is always a copy of reference, are we losing some "rvalue" optimizations? (I think Stateful Objects / Stateless Objects are basically lvalue / rvalue, respectively) For example, if a struct is small enough, even smaller than a pointer, and we know its address is never taken, wouldn't it be more profitable to just copy by values to avoid another pointer dereference? Furthermore, if only a single struct field (or attribute) is used, wouldn't it be more profitable to just pass that field value instead of passing around the reference to that struct, assuming there is no ABI issue? (the classic scalar replace of aggregate)

is it the mech-lang?

in case anyone who doesn't get the reference: https://youtu.be/b2F-DItXtZs?si=gxrqufTAy-YQ88wW

> constrain the length to the maximum vector size supported by the lowest platform you want to support or you lose the portability and actually end up with code that performs much worse than the scalar alternative on some platforms.

Or, put a dynamic factor into your vector size and design everything around it. Such that every platforms can plug in their own factor and _scale_ the size of vectors. This is basically what LLVM IR does for SVE and RVV: `<vscale x 4 x i32>` where vscale is the said dynamic factor. Though the exact value of vscale is only known during runtime, it doesn't matter -- we still can design compiler optimizations and lowering around it. The generated binaries can then be portable across platforms with different vscale values.

Just want to say among many portable SIMD solutions I’ve seen recently (e.g. Fearless SIMD), this is the first that makes non-fixed vectors like SVE and RISC-V vector (RVV) easier to support. Glad to see they made this decision

I disagree, compiler optimization and software ecosystem in general already take a really really really long time to build, and I think it'll take longer without a standardized low-level binary interface i.e. ISA to enable rapid distribution.

And the approach you mentioned here:

> a family of ISAs that are ABI compatible such that one can compile down to a semi-pre-optimized portable IR, and just do the last bit per ISA

I think this is basically WebAssembly and PTX, and one may argue, Java bytecode. Yet look at how much efforts and time it took for WASM runtimes and JVMs to actually produce performant machine code (the "last bit per ISA" you mentioned) for just a couple of architectures! (e.g. X86 and ARM). And I wouldn't surprised if NVIDIA pour even more money on building optimization pipeline from PTX to each of their different uArchs.

or have little vision to begin with

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