fix a potential issue in the pipeline pass

[scxiao]

The fix here is relate to the function call of op.getResult(0), in which an op could have zero results, then this function call will have an assert failed.

The fix is to check the number of results of an op before calling this function. Only if an op has 1 or more results, will the function op.getResult called.

[zhanglx13]

@scxiao Can you provide more context about the problem?

1. On which GPU did you see this error? Is it only on MI300?
2. For which input did you see this error?
3. For the input that triggers the error, what is op look like? Why does it have zero result?

[scxiao]

@scxiao Can you provide more context about the problem?

1. On which GPU did you see this error? Is it only on MI300?
   This is a general problem if we upstream the llvm project to the latest. Actually, yesterday, the openai/triton just upstreamed the llvm it uses and the changes they made include what I did in this PR. see https://github.com/openai/triton/blob/17eb982771e939406b6f801d80d51498507893dd/lib/Dialect/TritonGPU/Transforms/Pipeline.cpp#L391.

2. For which input did you see this error?
   I observed this problem when I ran the test_gemm.py. Specifically, this case can trigger the problem in this PR:
   pytest test_gemm.py::test_gemm[64-32-128-4-64-32-64]

3. For the input that triggers the error, what is op look like? Why does it have zero result?
   This is related to the for loop used in the gemm implementation. The for loop is optimized in the pipeline pass. It is rewritten to a bunch of OPs with the scf.yield as the terminator. scf.yield has 0 result, but in this pass, it assumes it has a default one result, which causes an assert failed in the function call of op.getResult(0). The reason it did not fail before is the assert as added to getResult() recently, and then this problem is surfaced.

[zhanglx13]

@scxiao So with the current llvm, getResult(0) does not fail even if there is no result to get for the op, right?
I just want to see a confirmation that upstream triton also has this problem and a fix for this problem. Then maybe we should wait for the PR#219 to take in the fix.
I also noticed that this PR has two more checks (op.getNumResults() > 0) compared to the upstream fix. Is there a reason for this difference?

[scxiao]

Changes in this PR is also included in in @jayfurmanek upstream PR #219, so close this PR.