About "esotic" operations about mlir-npcomp HOT 4 OPEN

That's not a bad intermediate test case, but will require a fair bit of basics to be right (but I don't see any fundamental issues).

My next step is to model the numpy ufunc abstraction in the numpy MLIR dialect. There are a few ways to do it, but I'm thinking of having a ufunc_call op which references a module level ufunc (which could be of a few different types) that holds the metadata about the operation.

Since the ufunc is such a core abstraction within numpy, and since it covers so many of the fundamental operations, it makes sense to me to spend some time to get it modeled isomorphic to how numpy reasons about it (at least modeling a proper subset of cases).

Beyond that, for your example, we would need:

• Indexing/slicing ops
• Some 'constructor ops' (zeros, etc)
• where
• dot

I'm trying to model it as isomorphic to numpy as is reasonable, since that is part of the MLIR philosophy and makes the tracer/ast-importer really-really thin, leaving the hard work to the compiler infra, which (in theory) is where we have the best tooling.

I'm going to try to get a first draft of the numpy dialect ~this week. I've been thinking on the design of it, but the limited time I've had to actually work on it has been swallowed up by setup/build issues (which I think I'm past now).

from mlir-npcomp.

Probably we could reply to this stackoverflow question one of these days. 😉

from mlir-npcomp.

Not touching the question of what TensorFlow should be doing, getting this modeled right is a big driver of my work here. Lacking this functionality has been a drag on research adjacent to me for quite some time.

from mlir-npcomp.

Of course, but I hope it will have repercussions elsewhere.

from mlir-npcomp.