Ensure type annotations are added for reference returning intrinsics/operators

[llvm-beanz]

If an intrinsic returns a reference to a new object or UDT that isn't guaranteed to have already been annotated by some other means, the current code fails to add a type annotation for this type (if it is used without being assigned/copied to a temporary variable first). If a non-reference type is added, the type annotation gets added during EmitAutoVarAlloca.

At present, it's unclear where this has impact. The order of operations here should be to find what else this type annotation gap might impact, write a test for that, and fix it.

[pow2clk]

@anupamachandra, do you think your work on #5358 is going to overlap with this?

[anupamachandra]

Yes, I believe so.

[anupamachandra]

@llvm-beanz I thought the issue was that the subscript operator for NodeOutputArray was defined as `T& operator versus T operator. That is not the case, it does return a value:

`-DeclRefExpr 0x21b5817eb70 <col:42, col:44> 'NodeOutput<Record> (unsigned int)' lvalue CXXMethod 0x21b5817e818 'operator[]' 'NodeOutput<Record> (unsigned int)'

Also, #5357 requires adding type annotations to reference types returned by intrinsics, with that in place, should this be changed to return a reference, consistent with the other HLSL types.

[llvm-beanz]

@tex3d may need to weigh in here. I know that I authored the public version of this issue, but Tex authored the original internal issue (111).

Tex had an internal comment:

The annotation may be missing because our code paths that add it aren't triggered for the an intermediate NodeOutput object in some cases, for example myNodeOutputArray[i] won't get a type annotation added because there's no explicit intermediate variable, because the operator[] returns a reference:

ThreadNodeOutputRecords<MyRecord> myRecords =
 myNodeOutputArray[i].GetThreadNodeOutputRecords(...);

But it would if you wrote it like this:

 NodeOutput<MyRecord> myOutput = myNodeOutputArray[i];
 ThreadNodeOutputRecords<MyRecord> myRecords =
 myOutput.GetThreadNodeOutputRecords(...);

Now, operator[] shouldn't return a reference in this case (which is one part of a fix, but I think that one wasn't trivial), and we also need to cover the reference case for adding the type annotation anyway.

We may just need testing to verify that these cases are correctly handled by the code in CGHLSLMSFinishCodeGen.cpp that creates node record handle annotations.

@tex3d thoughts?

[tex3d]

The issue was detected when the NodeOutputArray subscript operator returned a reference to a NodeOutput object, which was not correct. For returning the record struct itself (not the object), like what Get() and the Node*OutputRecords subscript operators return, these should be a reference. But when returning an object (handle), it should be a value (the object is synthesized, not pre-existing and referenced).

Now, the subscript operator was fixed, but the bug that can lead to a missing type annotation remains which might impact some other operator that returns a reference.

That's the issue: find what else this type annotation gap might impact, write a test for that, and fix it.

[tex3d]

To be clear, this no longer impacts the same work graph case, it might impact some other pre-existing scenario, it isn't a regression, therefore shouldn't be considered an SM 6.8 issue.