As people know, that area is by no means an uncharted territory,
there is a number of prior art there, with perhaps most famous one being
GitHub - halide/Halide: a language for fast, portable data-parallel computation.
However, would there be any interest in coming up with a yet another language,
but this time hopefully more closely tied to the LLVM project (aka, see Incubation),
and would anyone like to participate? I think, this might be a (but obviously not the)
missing piece in The LLVM Compiler Infrastructure. Or is this effort completely doomed?
Here’s my incomplete high-level inspirational fact-list:
- Making use of MLIR
- Inspired by the current Halide’s user-facing API, and, if not otherwise specified, mostly close to it
- two-layered user-facing font-end, with the nice C++/Python/etc one being built on top of the C one
- for integers, don’t enforce either behavior, allow making wrapping undefined
- better UX for when things go wrong:
- serialization support
- into the ground-level C front-end calls, effectively obfuscating the source – simpler bug reporting, allows creduce to be used
- naturally, natively, into
.mliror however it works in MLIR, allowing mlir-reduce to be used
- first-class sanitization support
- “(if possible!) either have an (optional) check for it, or don’t have that UB”
- (at least partial?) custom, early lowering for MSan/ASan handlers, with the idea being to, essentially, optimize two consecutive checks of two consecutive elements into a single wider check
- //maaybe// debug info?
- serialization support
- Modularity of internals, good end-to-end tests are good, but having unit tests may be good too
- Well-defined (aka, documented) internal behaviors/side-effects
- ??? (i’m sure i’m missing a few points here, there’s probably a few more ‘lessons learned’ kind of things that could fit here.)
- (help wanted :)) Translation verification
- Ideally, not being little-endian-only
Now, i want to acknowledge the obvious. The existing contenders have existing audience,
consumers and research going to them. Perhaps the ecosystem is already over-saturated,
and even if it is not, feature parity may be hard. Or not, depending on our ecosystem
So i don’t know if there will be any appetite for this, but i feel like some of the points are rather hard
to achieve starting from an existing project. So while I’m hopeful here, I’m possibly pointlessly so
My endgoal is not fancy at all, i simply wish to be able to write nicer image pixel operation code.
Or perhaps there already is a project that matches this rough description, that i do not know about?