Skip to content

Conversation

@farzonl
Copy link
Member

@farzonl farzonl commented Nov 13, 2025

fixes #502
https://godbolt.org/z/xaEE44cbE
Test 3 cases (loads and stores):

  1. single subscript as an l-value swizzle
  2. single subscript where the store/load takes a vector r-value swizzle
  3. single subscript where we store/load the vector as is.

https://godbolt.org/z/xaEE44cbE
Test 3 cases (loads and stores):
1. single subscript as an l-value swizzle
2. single subscript where the store/load takes a vector r-value swizzle
3. single subscript where we store/load the vector as is.
In[12], In[13], In[14],
In[15]);

for (int i = 0; i < 4; i++) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Why don't we follow coding standards in test? I've noticed this in lots of tests.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even in llvm-project we don't run clang-format on tests, but the capital I is a c++ coding standard for c/c++ in llvm-project. I wasn't aware we defined a coding standard for HLSL but I suppose we could adopt the c/c++ one?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. I was referring to the c/c++ coding standard. I didn't consider that it was c/c++ specific. It's just stood out to me for the variable names in tests we add. So, my nit really was more of a question. Just stands out to me.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a slight nuance here too, which is that Clang tests often deliberately do not conform to LLVM's coding standards. It would be pretty awful if Clang only worked on C/C++ code that conformed to LLVM's standards (one could imagine a parser bug that didn't properly handle tabs because LLVM disallows them, or CRLF line endings because LLVM biases toward LF).

I don't have a strong opinion on these specific cases. I do find code easier to read if it conforms to coding standards, but there are sometimes benefits to not conform.

In[15]);

for (int i = 0; i < 4; i++) {
int4 B;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

very minor nit, but a for loop for 4 assignments with two of them be 'special' made me look at this for a moment longer.
4 explicit assignment statements might be cleaner.

Copy link

@alsepkow alsepkow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Minor nit on the first for loop in both tests. Take it or leave it.

Copy link
Contributor

@Icohedron Icohedron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Just a few formatting/spacing nits

Comment on lines +7 to +12
int4x4 A = int4x4(In[0], In[1], In[2],
In[3], In[4], In[5],
In[6], In[7], In[8],
In[9], In[10], In[11],
In[12], In[13], In[14],
In[15]);
Copy link
Contributor

@Icohedron Icohedron Nov 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Formatting nit:

Suggested change
int4x4 A = int4x4(In[0], In[1], In[2],
In[3], In[4], In[5],
In[6], In[7], In[8],
In[9], In[10], In[11],
In[12], In[13], In[14],
In[15]);
int4x4 A = int4x4(In[0], In[1], In[2], In[3],
In[4], In[5], In[6], In[7],
In[8], In[9], In[10], In[11],
In[12], In[13], In[14], In[15]);

Comment on lines +7 to +8
int4 vec = int4(In[0], In[1], In[2],
In[3]);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Formatting nit

Suggested change
int4 vec = int4(In[0], In[1], In[2],
In[3]);
int4 vec = int4(In[0], In[1], In[2], In[3]);

Buffers:
- Name: In
Format: Int32
Data: [ 1, 2, 3, 4]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: There is an extra space here for some reason

Suggested change
Data: [ 1, 2, 3, 4]
Data: [1, 2, 3, 4]

Copy link

@tex3d tex3d left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor comments/suggestions, nothing necessarily requiring changes regarding:

  • dynamic/static subscript indexing and potential optimizations
  • symmetrical swizzles (equivalent when used in source or dest)

for (int i = 0; i < 4; i++) {
int4 B;
if (i % 2 == 0)
B = A[i];
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a comment, not a request for change:

These subscript accesses look dynamic, but these loops are likely to be unrolled, either before IR (in DXC, Clang, etc.) or after (in a driver compiler). That unrolling would make all accesses static, even eliminating the intermediate local variables to copy values directly from static indices of In to static indices of Out. That's a fine path to test, but this might not test other important dynamic indexing code paths, if desired.

I guess this gets at the fuzzy purpose issue with the offload-test-suite. This seems fine to test this scenario end-to-end, whatever path it may take through optimizations, and maybe that's all that's desired for this test.

Comment on lines +20 to +21
else
B.grab = A[i];
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Assignment swizzling is always harder to follow, but this one happens to be identical in mapping to the same swizzle if used on source instead. That seems a little too convenient, so maybe the target swizzle should be different to avoid that symmetry and make sure it's not treated the same somehow.

grab is symmetric (equivalent to grab on source):
B.grab = {5,6,7,8} -> {6,5,8,7}
B = {5,6,7,8}.grab -> {6,5,8,7}

agrb is not symmetric (equivalent to bgar on source):
B.agrb = {5,6,7,8} -> {7,6,8,5}
B = {5,6,7,8}.agrb -> {8,6,5,7}
B = {5,6,7,8}.bgar -> {7,6,8,5}

Perhaps a comment with the equivalent in source swizzle form would help too:

Suggested change
else
B.grab = A[i];
else // i == 1
B.agrb = A[i]; // equivalent: B = A[1].bgar

Corresonding update to expected values would be:

-    Data: [ 1, 2, 3, 4, 6, 5, 8, 7, 9, 10, 11, 12, 16, 15, 14, 13 ]
+    Data: [ 1, 2, 3, 4, 7, 6, 8, 5, 9, 10, 11, 12, 16, 15, 14, 13 ]

if (i % 2 == 0)
B = A[i];
else if (i % 3 == 0)
B = A[i].abgr;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: abgr is also a symmetric swizzle. bagr is another asymmetric swizzle you could use.

A[i] = vec;
// A[1] is reverse In Buffer
else
A[i] = vec.abgr;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: another symmetric swizzle.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Matrix] Implement tests for single subscript that allows vector r and l values aswell as vector swizzle

5 participants