Interest in a (perhaps simplistic) image processing front-end?

LLVM Project
1


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 :slight_smile:
      • naturally, natively, into .mlir or 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?
  • 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 :slight_smile:

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 :slight_smile:
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?

Roman.

1 Like
2

Ok, that was not unexpected.

Let’s reframe the question at hand.

@clattner @mehdi_amini onceptually, would something like that have a place
in the upstream LLVM ecosystem? (note that this is not a proper RFC for that.)