Hard-coded dimension sizes in emitted code

[fredrikbk]

We should have a lowering API that let's us specify which dimensions should be hard-coded in the emitted code. In the taco code generator tool (command-line/web) dimensions should not be hard-coded by default.

In the current C++ API, where an expression is with respect to specific tensors (with immutable dimensions) we should hard-code in all dimension sizes.

However, when we design an API to let users reuse expressions across different tensors (#72), then we should let users specify which dimensions should be constants. For example, as suggested by @peterahrens in #44, it often makes sense for a Blocked SpMV kernel to hard-code the size of the blocks, but not the outer dimension.

[ShadenSmith]

Sparse tensor kernels could also benefit from a mix of unspecified and specified dimensions. Namely, the matrix operands in various contractions (e.g., MTTKRP) typically have only a few columns but many rows. The optimizations for say a rank-1 vs a rank-512 MTTKRP are different, as the amount spatial locality radically changes. Small ranks should benefit from something like the scatter/gather instructions available in AVX-512, whereas larger ranks can just use traditional loads + FMA.

[fredrikbk]

One option is to specify which dimensions to hard-code (and not) in a scheduling construct Schedule that is passed to the lowering machinery.

A second option, as suggested by @peterahrens, is to specify this when we create tensors. E.g. Tensor<double> A(variable(10), 42).