Hongzheng Chen
Hongzheng Chen
> Can you show your use case? I'm thinking maybe I wrote this for some specific reasons. I guess `Simplify` is used in many places and sometimes we don't want...
> If the loops are eliminated, they can work? Yes, it can work. HLS can detect three functions here.
Maybe the best way is to generate modules/functions to explicitly distinguish different stages.
Did you forget uploading the `montgomery.py` file? I didn't see it in the PR, but it was used in the test file.
I found the problem. The simplification logic only works when the loop range is smaller than the array size. https://github.com/cornell-zhang/heterocl/blob/d3173471e877c32fd9327e882575499c46f10f69/tvm/src/pass/simple_passes.cc#L174-L176 I think it's unnecessary? And the correctness of the program...
> I found the problem. The simplification logic only works when the loop range is smaller than the array size. > https://github.com/cornell-zhang/heterocl/blob/d3173471e877c32fd9327e882575499c46f10f69/tvm/src/pass/simple_passes.cc#L174-L176 > > > I think it's unnecessary? These...
Also the [`test_schedule_compute.py/test_split_reorder`](https://github.com/cornell-zhang/heterocl/blob/master/tests/test_schedule_compute.py#L176-L177) case.
It makes sense. (a) and (b) should generate the same code. The newly generated loops should always be accessed by the returned variables like the code below. ```python outer, inner...
Any comments? @zhangzhiru @seanlatias @Hecmay
> > > Agreed. the abstraction is not clear enough, and it's too much work for users to use `.to` for each of the arguments. > > > We can...