rise-lang / mlir-doc Goto Github PK

Tuples are restricted to two elements, not only by the operation definition of arguments (LHS, RHS) but also the accessors (first, second), like C++ std::pair. However, in most languages (including C++), tuples can have more than two arguments (and accessed via std::get() for example).

I'm wondering why the restriction, and if it's a preliminary one, perhaps making the decision now would avoid having to reexamine all the assumptions later on.

MLIR uses "index" as the native integer for induction and length, maybe it would be more familiar to use that terminology, too?

Types don't seem to have fixed sizes in Rise.

def IntType : Type<CPred<"$_self.isa<Int>()">, "int type">;
def FloatType : Type<CPred<"$_self.isa<Float>()">, "float type">;

I'm assuming it becomes a decision of the dialect conversion which underlying standard type to use, perhaps using the native type of the underlying hardware (word size, FPR width, etc).

However, MLIR (and LLVM) use i1 to represent boolean values, and without a direct boolean type in Rise or a way to define bit-width, it's impossible to represent boolean values in Rise.

If/once conditionals are introduced as a first-class citizen, boolean values would be required. In that case, I'd assume creating a new BoolType would make more sense than allowing IntType to define the bit-width.

So far, Rise has add and mul.

It should also have sub and div as well as other reducing strategies like max and min, unary operations like neg and abs and possibly even primitives like sin, cos, exp, tan which could help implementing some ML workloads.

Rise seems to have only bound arrays, from literals. This is fine for small test cases but it gets annoying when writing functions that take in an array of any size and try to apply a map:

%map = rise.map #rise.nat<?> #rise.array<?, !rise.float> #rise.array<?, !rise.float>

Without unbound arrays, programs will either have to generate all variants (like templates) or inline everything to make sure all unbounded dimensions are defined at code generation, neither of which are generic enough.

MLIR has native conditionals via compare+branch operations, but that doesn't mean it works directly with the Rise dialect.

It could perhaps work when choosing which lambdas to apply but inside a lambda, the comparisons will have to be done on Rise types, not native, and there is not support (I can see) for it.

While many algorithms can be written without direct conditions (at least not in the lambdas), with vast examples in machine learning and HPC kernels, it would be impossible to convert existing generic code (including most HPC applications) into Rise.

Is there a plan to introduce conditional execution in Rise? Given the (side-effect free) lambda nature of Rise, I imagine a select would be simpler to implement and would cover a lot of the existing cases.