!tv_inps.empty() INTERNAL ASSERT FAILED (full + sum) about fuser HOT 4 CLOSED

I got this error with your repro and TOT:

Traceback (most recent call last):
  File "/home/nmaruyama/pytorch/debug3/nvfuser/repro.py", line 1, in <module>
    from nvfuser import FusionDefinition, DataType
  File "/home/nmaruyama/pytorch/debug3/nvfuser/nvfuser/__init__.py", line 15, in <module>
    from . import _C
ImportError: cannot import name '_C' from partially initialized module 'nvfuser' (most likely due to a circular import) (/home/nmaruyama/pytorch/debug3/nvfuser/nvfuser/__init__.py)

I don't have any problem with the python frontend tests:

(/opt/conda/pytorch) docker-pyt-cuda-117_debug3:nvfuser$ python python_tests/test_python_frontend.py                                                                                                               /home/nmaruyama/pytorch/debug3/pytorch/torch/backends/cudnn/__init__.py:93: UserWarning: PyTorch was compiled without cuDNN/MIOpen support. To use cuDNN/MIOpen, rebuild PyTorch making sure the library is visible to the build system.
  warnings.warn(
......................................................
----------------------------------------------------------------------
Ran 54 tests in 174.014s

OK

Does it need some other packages?

from fuser.

The issue code be running the repro from the root directory of the nvFuser repository. It seems to cause an issue.

from fuser.

I did try running it from the PyTorch directory but had the same error. The repro was placed in the nvfuser directory. I copied the repro to the PyTorch directory and ran it from there, and now it worked. No idea why.

Anyway, I was able to reproduce the failure. What the symptom indicates is there may be some logic error in the segmenter. More specifically, the segmenter completed the segmentation of the fusion and the heuristics of each segment was found, and then it tried to schedule each segment with the chosen heuristic, in this case a reduction heuristic, but it didn't find any reduction in the given segment, which shouldn't happen as the reduction heuristic was chosen. I've seen similar errors before, and for this one I'm guessing there must be some logic error. I don't know if it has anything to do with the full op and the reduction.

from fuser.

It was a much simpler bug. Fixed in #143

This fix isn't ideal as it segments at the full op and the following reduction. The reduction scheduler assumes there's an input, but that's not the case with the repro, so it failed. I'm sure we could support this pattern without segmentation, but I haven't looked into it yet.

How important to fuse patterns like this?

from fuser.