OpAccessChain should allow OpConstantNull for structures

[ianromanick]

The SPIR-V spec says:

Each of the Indexes must:

...
- be an OpConstant when indexing into a structure.

This is too restrictive. An OpConstantNull can also define an integer constant (of zero), so it should be allowed. For at least some SPIR-V generators, this will effectively mean that OpConstantNull cannot be used for scalar integers since the code that generates the constant may not know what the constant will be used for.

[johnkslang]

This is too restrictive. An OpConstantNull can also define an integer constant (of zero), so it should be allowed.

Understood. It seems possibly reasonable to expand this to include OpConstantNull, though I think it is okay without. Member numbers in structures don't come from unknown sources, they come from the member name after the "." (in a typical C-like language), and 0 only comes for the first member. Not sure how that would get conflated with an integer of unknown future use.

[ianromanick]

I have a function emit_constant. It emits one or more of OpConstant, OpConstantNull, OpConstantTrue, OpConstantFalse depending on the type and value of the constant, or it returns the ID of one of those that was already emitted. If emit_constant is called with a scalar integer zero, the emit_constant function doesn't know whether that 0 will be used as an array index in an OpAccessChain, a structure index in an OpAccessChain, or as an operand to an OpIAdd. The first call to emit_constant may use the constant for one purpose while the next call may use the constant for a different purpose. Since I don't ever want to emit both an OpConstant of zero and an OpConstantNull, the only safe thing is to always emit the OpConstant of zero. This seems a shame since SPIR-V has OpConstantNull to represent zero-valued constants more compactly.

I hope this clarifies things.

[johnkslang]

Your function should return OpConstant 0 for scalar indexes and other integers. The only reason it needs to emit OpConstantNull is for 0-initialized aggregates, null abstracts, and null pointers (in graphics, a special case of a null abstract). This can all be done from the type, without knowing exact future use.

[johnkslang]

We could also complain about OpConstantNull and OpConstantFalse. I think it helps to consider the motivation of OpConstantNull as being for aggregates, which necessarily has to be defined recursively, bottoming out in terms of scalars. There may be something to improve in the language about this, but it certainly has a method of working quite well as is.