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?

Qualcomm has an enormous incentive in breaking Nvidia's CUDA grip on GPU programming.

Having Mojo support multiple platforms creates incentive to adopt Mojo and therefore write code in a language which can compile and run on Qualcomm hardware. This is good for Qualcomm.

However the danger is that the language sees wide adoption but nobody uses it with Qualcomm hardware. Instead it might encourage people to buy AMD. This is a terrible outcome for Qualcomm. They paid to boost someone else's sales.

So the incentive is to make sure it runs best on Qualcomm and to at least slightly hobble other hardware. But the safest thing overall is to support Nvidia, Qualcomm, and that's it.

I think a strategy for Qualcomm would be to use Mojo and Max as a software platform to drive AI inference on ARMv9 chips such as Snapdragon either at the edge (your smartphone) or in the cloud.

Ok, what will be Qualcomm incentive? Selling few hundred Mojo license for few thousand dollars each. Or making it open source hoping it may make big in AI / data science community and may help sell more Qualcomm hardware?

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

Of course it is. Emulating parallel operations on 4 or 8 or 16 or 32 elements one at a time using scalar instructions is expected to be slow.

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

That depends on which array & extrusive linked list classes you’re talking about. Let me put it another way: in three decades of professional coding in scientific computing, video games, film vfx, web programming, and GPU driver and hardware development, I’ve never had to reach for an extrusive linked list for work. I’ve only ever used them for learning, teaching, and toy projects.