This is an archive of the discontinued LLVM Phabricator instance.

[HLSL] Fix MSFT Attribute parsing, add numthreads
ClosedPublic

Authored by beanz on Mar 28 2022, 6:52 PM.

Details

Summary

HLSL uses Microsoft-style attributes [attr], which clang mostly
ignores. For HLSL we need to handle known Microsoft attributes, and to
maintain C/C++ as-is we ignore unknown attributes.

To utilize this new code path, this change adds the HLSL numthreads
attribute.

Diff Detail

Event Timeline

beanz created this revision.Mar 28 2022, 6:52 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 28 2022, 6:52 PM
Herald added a subscriber: StephenFan. · View Herald Transcript
beanz requested review of this revision.Mar 28 2022, 6:52 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 28 2022, 6:52 PM
Herald added a subscriber: sstefan1. · View Herald Transcript

Looks good. I made a comment about the CS 4.0 thing, but that can be addressed when more thorough examination of the requested shader models comes around.

clang/lib/Sema/SemaDeclAttr.cpp
6857

As we discussed, compute shaders didn't actually exist pre-4.0 and I don't know that we'll ever seek to do anything with a 4.0 shader model except convert it to a higher version and issue a notification, but that handling is clearly not the intent of this change. So it's fine with me.

rnk accepted this revision.Mar 29 2022, 1:27 PM

lgtm

clang/include/clang/Basic/AttrDocs.td
6377

I think it would be fair to link to the Microsoft docs here:
https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/sm5-attributes-numthreads

We've done this elsewhere for Microsoft attributes.

clang/lib/Sema/SemaDecl.cpp
11326

Style nit: comments should use follow normal capitalization and punctuation rules: "When writing comments, write them as English prose, using proper capitalization, punctuation, etc."
https://llvm.org/docs/CodingStandards.html#commenting

This revision is now accepted and ready to land.Mar 29 2022, 1:27 PM
This revision was landed with ongoing or failed builds.Mar 29 2022, 3:17 PM
This revision was automatically updated to reflect the committed changes.
aaron.ballman added inline comments.Mar 30 2022, 5:12 AM
clang/test/SemaHLSL/num_threads.hlsl
48

There are a few test cases that are missing here:

  1. Writing the attribute on the wrong subject.
  2. Passing no args to the attribute, passing too many args to the attribute.
  3. Function merging where the redeclaration has attributes that don't match. e.g.,
[numthreads(1, 2, 3)] void func();
[numthreads(4, 5, 6)] void func() {}
  1. Should the user be able to pick the values via NTTP or other constant expressions? e.g.,
template <int X, int Y, int Z>
[numthreads(X, Y, Z)] void func();

constexpr int foo();
[numthreads(foo(), 2, 3)] void other_func();
  1. Can you write this attribute on a member function? Can the member function be virtual?
beanz added inline comments.Mar 30 2022, 6:24 AM
clang/test/SemaHLSL/num_threads.hlsl
48

Great catches!

1-3 are definitely missing coverage. I'll add additional coverage. I also should add a test case where a value is a preprocessor macro.

For 4 & 5, the short answer is that HLSL doesn't support those situations, but I think there are two related diagnostics that I should be emitting:

  1. Applying the numthreads attribute on a template function should warn (It won't work anyways, but better to issue the diagnostic)
  2. Applying the numthreads attribute on a member function should

The point by point explanation is:

  1. Constexpr isn't supported at all, and user-defined templates are new to HLSL 2021, can't be used as entry functions. This _could_ be relaxed in the future, but we would need to force instantiation, which probably means some form of extern template support, which we don't have in the language yet.
  2. Member functions also can't be used as entry functions, and HLSL doesn't support anything virtual.

I'll update the tests and diagnostics today.

@aaron.ballman I pushed updates in rGff6696c842ba.

The one bit we discussed that I didn't do anything for is the template case. Neither clang or the HLSL compiler support parsing Microsoft attributes on templates right now, so the parser falls over and errors. It would be better to have a nicer diagnostic, but since the current state matches our compiler I left it as-is.

Thank you!

@aaron.ballman I pushed updates in rGff6696c842ba.

The one bit we discussed that I didn't do anything for is the template case. Neither clang or the HLSL compiler support parsing Microsoft attributes on templates right now, so the parser falls over and errors. It would be better to have a nicer diagnostic, but since the current state matches our compiler I left it as-is.

That sounds reasonable to me.

Thank you!

Thanks for the post-commit changes! One question on them:

def GlobalFunction
    : SubsetSubject<Function, [{S->isGlobal()}], "global functions">;

Are you sure that's what you want? This returns true for a static C++ member function, false for a static free function, and false for within an unnamed namespace, and true otherwise.

Also, I didn't see any new test coverage for function merging behavior.

beanz added a comment.Mar 30 2022, 4:32 PM

Are you sure that's what you want? This returns true for a static C++ member function, false for a static free function, and false for within an unnamed namespace, and true otherwise.

You're right this isn't quite right, but getting closer... HLSL doesn't support unnamed namespaces, and we only support static free functions by accident... (the current compiler ignores static on free functions).

This actually revealed some gaps in the documentation for HLSL, I've gone back and gotten feedback from my team's HLSL expert and I think I've got the right set of constraints for where this can be applied now (clang will even have this better than the HLSL compiler).

Also, I didn't see any new test coverage for function merging behavior.

Doh! I knew I was forgetting something. Juggling too many balls today. I'll get that covered too!

Are you sure that's what you want? This returns true for a static C++ member function, false for a static free function, and false for within an unnamed namespace, and true otherwise.

You're right this isn't quite right, but getting closer... HLSL doesn't support unnamed namespaces, and we only support static free functions by accident... (the current compiler ignores static on free functions).

This actually revealed some gaps in the documentation for HLSL, I've gone back and gotten feedback from my team's HLSL expert and I think I've got the right set of constraints for where this can be applied now (clang will even have this better than the HLSL compiler).

SGTM, thanks for digging into it!

Also, I didn't see any new test coverage for function merging behavior.

Doh! I knew I was forgetting something. Juggling too many balls today. I'll get that covered too!

No worries, thanks for following up on it. :-)

beanz added a comment.Mar 31 2022, 9:35 AM

I just pushed one more commit rG19054163e11a6632b4973c936e5aa93ec742c866 that further refines the subject specification and covers the merging attributes and conflicting attributes on the same decl.

Thank you so much for the spectacular review feedback!