Aliasing of pointers cast from integers is unclear

[nanokatze]

Consider the following GLSL program:

            #version 460

            #extension GL_EXT_buffer_reference                 : require
            #extension GL_EXT_buffer_reference2                : require
            #extension GL_EXT_buffer_reference_uvec2           : require
            #extension GL_EXT_scalar_block_layout              : require
            #extension GL_EXT_shader_explicit_arithmetic_types : require

            #pragma use_vulkan_memory_model

            layout(buffer_reference, scalar) buffer uintPtr {
                uint data;
            };

            layout(buffer_reference, scalar) buffer floatPtr {
                float data;
            };

            void main() {
                uint64_t addr = 0xdeadbeef00l; /* assume this location is valid */
/* 21 */        uintPtr(addr).data = 42;
/* 22 */        floatPtr(addr).data = 1.0;
            }

lines 21 and 22 each will be translated into a sequence of OpConvertUToPtr and OpStore without any aliasing-related decorations. Vulkan SPIR-V doesn't seem to say anything about aliasing of pointers obtained by converting from an integer and it's thus unclear why the above program is valid.

[Tobski]

There are a few bits of the SPIR-V spec that jump out at me:

If the type an OpVariable points to is a pointer (or array of pointers) in the PhysicalStorageBuffer storage class, the OpVariable must be decorated with exactly one of AliasedPointer or RestrictPointer.

If an OpFunctionParameter is a pointer (or array of pointers) in the PhysicalStorageBuffer storage class, the function parameter must be decorated with exactly one of Aliased or Restrict.

If an OpFunctionParameter is a pointer (or array of pointers) and the type it points to is a pointer in the PhysicalStorageBuffer storage class, the function parameter must be decorated with exactly one of AliasedPointer or RestrictPointer.

Also

For variables holding PhysicalStorageBuffer pointers, applying the AliasedPointer decoration on the OpVariable indicates that the PhysicalStorageBuffer pointers are potentially aliased. Applying RestrictPointer is allowed, but has no effect. Variables holding PhysicalStorageBuffer pointers must be decorated as either AliasedPointer or RestrictPointer. Only those memory object declarations decorated with Aliased or AliasedPointer may alias each other.

And:

AliasedPointer
Apply only to a memory object declaration, to indicate the compiler is to generate accesses to the pointer stored in the variable that work correctly in the presence of aliasing. See the aliasing section for more detail.

All of these do seem to suggest how aliasing works for pointers, but says nothing about the aliasing (or decoration thereof) for pointer casts. Feels like we either need to make a ruling (that they're always aliased) or that we need to allow the decoration on casts.

[Hugobros3]

I believe this is the same as: #93

Clarifications would be most welcome !

[raunraun]

The working group is actively discussing this and #93. Guidance will be provided shortly

[raunraun]

The SPIR-V Working believes that existing wording (added in SPIR-V 1.5) covers this case.

Because aliasing, as described above, only applies to memory object declarations, a consumer does not make any assumptions about whether or not memory regions of non memory object declarations overlap. As such, a consumer needs to perform dependency analysis on non memory object declarations if it wishes to reorder instructions affecting memory. Behavior is undefined if operations on two memory object declarations access the same memory location, with at least one of them performing a write, and at least one of the memory object declarations does not have the Aliased decoration.

Also see this change in SPIR-V 1.5rev5

#678: Allow the AliasedPointer and RestrictPointer decorations to apply to memory object declarations.

WIth these 2 existing paragraphs, we think pointers created 'out of thin air' are not 'memory object declarations' and are thus 'aliased' by default.

Any thoughts?

[nanokatze]

Thanks, makes sense as there's not much useful we can do with an out of thin air pointer that is unrelated to (doesn't alias) anything else, but it's great to have reassurance