Check whether array element is fully specialized

[kaizhangNV]

close #5776

When we start specialize a "specialize" IR, we should
make sure all the elements are fully specialized, but
we miss checking the elements of an array. This change
will check the it.

[csyonghe]

I wonder why this case is necessary.
If we have an type that is T.Differential[N], then it shall be encoded as IRArrayType(IRLookupWitness(w, "Differential"), N), and since IRLookupWitness has operand w, it won't appear in global scope, and therefore the IRArrayType itself won't appear directly in the global scope, and therefore it won't be reported as true by the default case logic.

Basically, if the element type is not fully specialized, then the array type itself shouldn't appear in the global scope. What IR are you seeing?

[kaizhangNV]

Yes, this case this necessary, the unit test can reproduce the case.

[csyonghe]

I ask this question because in theory this shouldn’t happen, otherwise we will have the same issue for Ptr type and all other kinds of wrapper types.

[kaizhangNV]

If you dump the IR from the unit test, you will find out:

Ptr(specialize(%84, specialize(%150, Float, 1 : Int, %168)))	= get_field_addr(%callx5Fdata, %result)

this could result as:

	struct %GradInBuffer	: Type
	{
		field(%gradx5Fin, specialize(%82, lookupWitness( witness_table_t(%IDifferentiable)(Array(Float, 1)),   %37)))
	}

and finally this lookup table will give us

Array(lookupWitness(%168, %37), %N6)

here is the case I need to handle.

[csyonghe]

I see. In this case we do need to also handle all other opcodes by recursively checking their operands. Because we could have PtrType(lookupWitness()), or ArrayType(int, lookupwitness()), etc.

[kaizhangNV]

I always hit this:

type argument 'float[1]' does not conform to the required interface 'IFoo'

not sure what's wrong regarding extending Array to conform to IFoo.

[csyonghe]

In your syntax you specified T:IFoo, since float !: IFoo, Array<float,1> !: IFoo.

[kaizhangNV]

Oh, I see the problem, I forgot removing that line.

OK, I will see if I can craft a shader to reproduce this issue.

[csyonghe]

For a repro, you probably need to define an associatedtype in the interface for lookupwitness to occur inside an array type

for example, something like:

interface IFoo
{
      associatedtype FA : IFoo;
     int get();
}
struct X : IFoo { typealias FA = X;  int get() { return -1; } }
extension<T, int n> Array<T, n> : IFoo
{
      typealias FA = X;
}

int test<T:IFoo>(T.FA v[2]) {
     return v[0].get();
}

...

[kaizhangNV]

I wrote another shader a little bit different from yours, but now I can get stable reproduce.

[kaizhangNV]

Update the patch to cover all wrapper types, also added more test cases.

[csyonghe]

Also: TupleType, OptionalType, TypePack.

we should define a isBuiltinGenericType() utility in slang-it-util that returns true for these opcodes so that we don’t have to duplicate these switch cases all over the place.

[kaizhangNV]

sure.

An extra question, in the test, I actually want to cover the case like:

StructuedBuffer< StructuredBuffer > input;

but I'm struggled with how to feed data to this type.

From the generated code, I do see we handle this situation correctly, but I didn't cover this in the test as I don't know how to feed data.

[csyonghe]

This is an invalid type. Slang should check and report error on this.

[kaizhangNV]

miss the inner generic parameter, is this the invalid type?
StructuedBuffer< StructuredBuffer<float> >

[kaizhangNV]

Also: TupleType, OptionalType, TypePack.

we should define a isBuiltinGenericType() utility in slang-it-util that returns true for these opcodes so that we don’t have to duplicate these switch cases all over the place.

Done of adding this.