Support for SPV_INTEL_cache_controls

[aratajew]

Specification: KhronosGroup/SPIRV-Registry#216

[MrSidims]

Overall LGTM
Would it be possible to decorate user function calls that affect memory? Is it possible to decorate LifetimeStart/End instructions (this case seems to be unhandled).

[MrSidims]

As the spec is public, please move these definitions to https://github.com/KhronosGroup/SPIRV-Headers

[aratajew]

Created PR for SPIRV-Headers: KhronosGroup/SPIRV-Headers#376

[MrSidims]

We kinda decorate ***AccessChain*** instructions, should we add them in the check?

[aratajew]

I don't think it's necessary. We know that Load's 2nd parameter is 'OpTypePointer' type and we want to make sure that it's properly decorated. It doesn't matter from what instruction the pointer comes from.

[aratajew]

Would it be possible to decorate user function calls that affect memory? Is it possible to decorate LifetimeStart/End instructions (this case seems to be unhandled).

I'm not sure if I understand the question. The decoration is applied to OpTypePointer, not to instructions and it has only effect if the decorated pointer is directly used by load/store instruction.

[MrSidims]

Would it be possible to decorate user function calls that affect memory? Is it possible to decorate LifetimeStart/End instructions (this case seems to be unhandled).

I'm not sure if I understand the question. The decoration is applied to OpTypePointer, not to instructions and it has only effect if the decorated pointer is directly used by load/store instruction.

No, it's being applied not to OpTypePointer but to an object of this type, see the test:

; CHECK-SPIRV-DAG: Load {{[0-9]+}} {{[0-9]+}} [[**LoadPtr**:[0-9]+]]
; CHECK-SPIRV-DAG: Decorate [[LoadPtr]] CacheControlLoadINTEL 0 1

and OpLoad definition is the following:

OpLoad
Pointer is the pointer to load through. **Its type must** be an OpTypePointer whose Type operand is the
same as Result Type.
4 + variable 61 <id>| Result Type | Result <id> <id> | **Pointer** |Optional Memory Operands

So Pointer is not a type, but a result id of an instruction, that can create an object of OpTypePointer, like alloca / OpVariable or AccessChain instruction or LifetimeStart instruction or some other instruction.

UPD probably it doesn't matter, as actually LifetimeStart doesn't return a pointer, but just specifies when it's defined. Yet a question about OpFuctionCall returning a pointer remains

[aratajew]

Would it be possible to decorate user function calls that affect memory? Is it possible to decorate LifetimeStart/End instructions (this case seems to be unhandled).

I'm not sure if I understand the question. The decoration is applied to OpTypePointer, not to instructions and it has only effect if the decorated pointer is directly used by load/store instruction.

No, it's being applied not to OpTypePointer but to an object of this type, see the test:

; CHECK-SPIRV-DAG: Load {{[0-9]+}} {{[0-9]+}} [[**LoadPtr**:[0-9]+]]
; CHECK-SPIRV-DAG: Decorate [[LoadPtr]] CacheControlLoadINTEL 0 1

and OpLoad definition is the following:

OpLoad
Pointer is the pointer to load through. **Its type must** be an OpTypePointer whose Type operand is the
same as Result Type.
4 + variable 61 <id>| Result Type | Result <id> <id> | **Pointer** |Optional Memory Operands

So Pointer is not a type, but a result id of an instruction, that can create an object of OpTypePointer, like alloca / OpVariable or AccessChain instruction or LifetimeStart instruction or some other instruction.

UPD probably it doesn't matter, as actually LifetimeStart doesn't return a pointer, but just specifies when it's defined. Yet a question about OpFuctionCall returning a pointer remains

Right, that's what I meant, just not said it precisely enough. Every object of type OpTypePointer can by decorated, so OpFunctionCall returning a pointer can also be decorated.