Nicolas Vasilache

Nice work Scott! Looking forward to playing with it

``` But really long term we should not rely on scf.for_each construct. We have debated it a lot, and it doesnt gel well with IREEs constraints. It will be hard...

@caffe2bot retest this please

After looking a bit deeper at the impl, I am not a fan of having 2 ways of specifying the strides during codegen (both Halide and TensorInfo) so we should...

> I don't agree with this reasoning. It's not because we _can_ do something that we necessarily need to do it. Yeah that's essentially my motto. Who said we *need*...

At some point I will also reconsider pulling this piece of [code](https://github.com/facebook/fbcuda/blob/master/DeviceTensor.cuh) we had been using in ancient days. There is no particular reason to limit ourselves to subarray semantics,...

Also, note that there is a tradeoff: 1. hardcoding the strides in the kernel which forces us to recompile each time there is a change in strides; 2. using parametric...

> Doesn't changing the strides usually change the sizes too? That's because strides in an overloaded term .. in this instance polyhedral folks have been using it improperly IMO. Sizes...

I have read the previous comments and I would like to add some insights about the difference between what we **could do** and what we **should do**. The following is...

So I think we have both the top down and the bottom up views summarized here, thanks for your input. If I put those things together: > Having every run...