[SM6.9] Allow native vectors longer than 4 #7143

pow2clk · 2025-02-18T16:20:11Z

Remove errors in Sema diagnostics for vectors longer than 4 in 6.9.
Test for failures using long vectors in unspported contexts and for correct codegen in
supported contexts. Verify errors persist in pre-6.9 shader models

The type buffer cache expects a max vector size of 4. By just skipping the cache for longer vectors, we don't overrun and store float7 vectors in the double3 slot or retrieve the double3 in place of float7.

Testing is for acceptance, mangling and basic copying that takes place
at the high level to ensure they are being accepted and recognized
correctly. The intent is not to tully test the passing of data as that
requires enabling vector operations to do properly. This test is used to
verify that these same constructs are disallowed in 6.8 and earlier.

A separate test verifies that disallowed contexts produce the
appropriate errors

Fixes #7117

Remove errors in Sema diagnostics for vectors longer than 4 in 6.9. Test for failures using long vectors in unspported contexts and for correct codegen in supported contexts. Verify errors persist in pre-6.9 shader models The type buffer cache expects a max vector size of 4. By just skipping the cache for longer vectors, we don't overrun and store float7 vectors in the double3 slot or retrieve the double3 in place of float7. Testing is for acceptance, mangling and basic copying that takes place at the high level to ensure they are being accepted and recognized correctly. The intent is not to tully test the passing of data as that requires enabling vector operations to do properly. This test is used to verify that these same constructs are disallowed in 6.8 and earlier. A separate test verifies that disallowed contexts produce the appropriate errors Fixes microsoft#7117

Disallow long vectors, and arrays or structs containing long vectors in cbuffers, entry functions, node records, tessellation patchs, or special intrinsic parameters with user-defined struct parameters.

This got lost somewhere

alsepkow · 2025-02-18T23:59:29Z

tools/clang/lib/AST/ASTContextHLSL.cpp

-                                    TypeSourceInfo *defaultTypeArgValue) {
+CXXRecordDecl *hlsl::DeclareTemplateTypeWithHandle(
+    ASTContext &context, StringRef name, uint8_t templateArgCount,
+    TypeSourceInfo *defaultTypeArgValue, InheritableAttr *Attr) {


minor nit: Why the difference in signature formatting in this file? See 'DeclareRecordTypeWithHandleAndNoMemberFunctions'. Most look look like they match the formatting you swapped to.

I think you are referring to whether the return type is on the same line or not? The answer is that right or wrong, we succumb to clang-format as even with its inconsistent foibles, it is preferable to chaos. It's the same argument that can lead to tyranny in other contexts, but for code formatting, it's an acceptable sacrifice with only occasional irritations.

clang-format will move arguments or return types seemingly arbitrarily to make the line fit within 80 characters. I support the 80 characters, but I wish it would let me decide whether moving return or argument is more readable. We literally cannot submit unless clang-format is happy though and I have bigger concerns.

alsepkow · 2025-02-19T00:08:53Z

tools/clang/lib/Sema/SemaHLSL.cpp

+  }
+
+  if (IsHLSLVecType(qt)) {
+    if (GetHLSLVecSize(qt) > 4)


4

Would this be better defined as a constant somewhere?

I agree we should reduce the number of places we put the magic value. Can we make this a language option though? Then we can query the Language Options for something like maxSupportedVectorSize()?

llvm-beanz · 2025-02-19T01:37:25Z

tools/clang/include/clang/Basic/DiagnosticSemaKinds.td

@@ -7843,6 +7841,8 @@ def err_hlsl_load_from_mesh_out_arrays: Error<
   "output arrays of a mesh shader can not be read from">;
 def err_hlsl_out_indices_array_incorrect_access: Error<
   "a vector in out indices array must be accessed as a whole">;
+def err_hlsl_unsupported_long_vector: Error<
+   "Vectors of over 4 elements in %0 are not supported">;


Seems like the element count could be a format argument too so that we can error on vectors too large for the large-vectors proposal too?

I did forgot about checking for vectors over 1024. The argument this has is meant to indicate the specific environment where such vectors aren't allowed, so I think I'll add a new error for the general prohibition. I don't mind adding the size as a param to this though it will almost certainly always be 4.

llvm-beanz · 2025-02-19T01:39:23Z

tools/clang/include/clang/Sema/SemaHLSL.h

@@ -128,6 +128,8 @@ unsigned CaculateInitListArraySizeForHLSL(clang::Sema *sema,
                                          const clang::InitListExpr *InitList,
                                          const clang::QualType EltTy);

+bool HasLongVecs(const clang::QualType &qt);


nit: IIUC, this is really checking if the type passed in contains a sub-object of long vector type?

Suggested change

bool HasLongVecs(const clang::QualType &qt);

bool ContainsLongVecSubObject(const clang::QualType &);

I didn't spend too much time considering this name. With other changes, I see this taking a max length param which makes the "long" in "longvec" subjective, but I'll name it something similar to your suggestion.

I don't think it should take a maximum length parameter, isn't a "long" vector anything over 4?

llvm-beanz · 2025-02-19T01:40:23Z

tools/clang/lib/AST/ASTContextHLSL.cpp

@@ -1131,6 +1135,9 @@ hlsl::DeclareConstantBufferViewType(clang::ASTContext &context, bool bTBuf) {
  typeDeclBuilder.addField(
      "h", context.UnsignedIntTy); // Add an 'h' field to hold the handle.

+  typeDeclBuilder.getRecordDecl()->addAttr(
+      HLSLCBufferAttr::CreateImplicit(context));


I really appreciate this cleanup. Thank you for doing this.

llvm-beanz · 2025-02-19T01:42:51Z

tools/clang/lib/Sema/SemaHLSL.cpp

+    const auto *SM =
+        hlsl::ShaderModel::GetByName(m_sema->getLangOpts().HLSLProfile.c_str());
+    if (!sintValue.isStrictlyPositive() ||
+        (sintValue.getLimitedValue() > 4 && !SM->IsSM69Plus())) {


I thought we were not requiring SM 6.9 for long vectors. Am I misreading this or misremembering?

In the meeting Monday the 10th, I brought up the issue and was told to do what I felt was right. I feel it's right to tie long vectors to native vectors in support matrices because it doesn't take too long a vector before the sequence of extractions and insertions becomes really cumbersome, slowing compile time and ballooning the DXIL size. As we discussed today, I'll add more rationale in the spec.

Okay, that seems like a reasonable rationale. Separately maybe we should consider if supporting shorter long vectors in old shader models is reasonable. I was looking at some compute shaders last week that bent over backwards to create 8-element vector types which might benefit from a smaller relaxing of vector size limitations.

llvm-beanz · 2025-02-19T01:44:14Z

tools/clang/lib/Sema/SemaHLSL.cpp

+    const RecordDecl *recordDecl = recordType->getDecl();
+    if (recordDecl->isInvalidDecl())
+      return false;
+    RecordDecl::field_iterator begin = recordDecl->field_begin();


What about base classes?

llvm-beanz · 2025-02-19T01:44:56Z

tools/clang/lib/Sema/SemaHLSL.cpp

+  if (qt.isNull()) {
+    return false;
+  }


nit:

Suggested change

if (qt.isNull()) {

return false;

}

if (qt.isNull())

return false;

tools/clang/lib/Sema/SemaHLSL.cpp

llvm-beanz · 2025-02-19T02:20:54Z

tools/clang/lib/Sema/SemaHLSL.cpp

+    const ArrayType *arrayType = qt->getAsArrayTypeUnsafe();
+    return HasLongVecs(arrayType->getElementType());
+  } else if (qt->isStructureOrClassType()) {
+    const RecordType *recordType = qt->getAs<RecordType>();


We could potentially avoid doing the record decl traversal at all if we take a bit from DefinitionData and cache it as we add members and base classes to the decl.

It's an interesting idea. I didn't like the recursion and throwing in base classes just adds to the overhead.

This is requiring a lot more additional code than I am inclined to put in here. In particular, various template parameters are not instantiated until after the checks are done now, so the DefintionData is set way too late. We have some forcing of instantiation, but only if the parameter is a template itself. @llvm-beanz Will you still consider approving the change without this?

I'm a bit surprised by this, DefinitionData tends to get updated as members get added into records, so I would have expected it to be sufficiently easy to update this in the addMember function.

I don't consider this a blocker if it is more complicated than I expected.

It's mainly the ConstantBufer usage where the template parameter is already weird and doesn't get addressed in the usual order of things. Other usages might be easier, but that was the one I started with.

tools/clang/lib/Sema/SemaHLSL.cpp

tools/clang/include/clang/Basic/Attr.td

pow2clk

Thanks for the feedback! Followup commit soon.

pow2clk · 2025-02-20T22:58:18Z

tools/clang/lib/AST/ASTContextHLSL.cpp

-                                    TypeSourceInfo *defaultTypeArgValue) {
+CXXRecordDecl *hlsl::DeclareTemplateTypeWithHandle(
+    ASTContext &context, StringRef name, uint8_t templateArgCount,
+    TypeSourceInfo *defaultTypeArgValue, InheritableAttr *Attr) {


I think you are referring to whether the return type is on the same line or not? The answer is that right or wrong, we succumb to clang-format as even with its inconsistent foibles, it is preferable to chaos. It's the same argument that can lead to tyranny in other contexts, but for code formatting, it's an acceptable sacrifice with only occasional irritations.

clang-format will move arguments or return types seemingly arbitrarily to make the line fit within 80 characters. I support the 80 characters, but I wish it would let me decide whether moving return or argument is more readable. We literally cannot submit unless clang-format is happy though and I have bigger concerns.

pow2clk · 2025-02-20T23:01:30Z

tools/clang/lib/Sema/SemaHLSL.cpp

+    const auto *SM =
+        hlsl::ShaderModel::GetByName(m_sema->getLangOpts().HLSLProfile.c_str());
+    if (!sintValue.isStrictlyPositive() ||
+        (sintValue.getLimitedValue() > 4 && !SM->IsSM69Plus())) {


In the meeting Monday the 10th, I brought up the issue and was told to do what I felt was right. I feel it's right to tie long vectors to native vectors in support matrices because it doesn't take too long a vector before the sequence of extractions and insertions becomes really cumbersome, slowing compile time and ballooning the DXIL size. As we discussed today, I'll add more rationale in the spec.

tools/clang/lib/Sema/SemaHLSL.cpp

tools/clang/include/clang/Basic/Attr.td

pow2clk · 2025-02-20T23:12:09Z

tools/clang/include/clang/Basic/DiagnosticSemaKinds.td

@@ -7843,6 +7841,8 @@ def err_hlsl_load_from_mesh_out_arrays: Error<
   "output arrays of a mesh shader can not be read from">;
 def err_hlsl_out_indices_array_incorrect_access: Error<
   "a vector in out indices array must be accessed as a whole">;
+def err_hlsl_unsupported_long_vector: Error<
+   "Vectors of over 4 elements in %0 are not supported">;


I did forgot about checking for vectors over 1024. The argument this has is meant to indicate the specific environment where such vectors aren't allowed, so I think I'll add a new error for the general prohibition. I don't mind adding the size as a param to this though it will almost certainly always be 4.

pow2clk · 2025-02-20T23:19:50Z

tools/clang/include/clang/Sema/SemaHLSL.h

@@ -128,6 +128,8 @@ unsigned CaculateInitListArraySizeForHLSL(clang::Sema *sema,
                                          const clang::InitListExpr *InitList,
                                          const clang::QualType EltTy);

+bool HasLongVecs(const clang::QualType &qt);


I didn't spend too much time considering this name. With other changes, I see this taking a max length param which makes the "long" in "longvec" subjective, but I'll name it something similar to your suggestion.

pow2clk · 2025-02-20T23:29:36Z

tools/clang/lib/Sema/SemaHLSL.cpp

+    const ArrayType *arrayType = qt->getAsArrayTypeUnsafe();
+    return HasLongVecs(arrayType->getElementType());
+  } else if (qt->isStructureOrClassType()) {
+    const RecordType *recordType = qt->getAs<RecordType>();


It's an interesting idea. I didn't like the recursion and throwing in base classes just adds to the overhead.

tools/clang/lib/Sema/SemaHLSL.cpp

pow2clk · 2025-02-20T23:34:30Z

tools/clang/test/SemaHLSL/hlsl/types/invalid_longvec_decls.hlsl

@@ -0,0 +1,132 @@
+// RUN: %dxc  -DTYPE=float -DNUM=7 -T ps_6_9 -verify %s


Reminder to self to add tests for vectors longer than 1024 as well as structs with base classes containing long vectors in all the forbidden locations.

…decls_pr

Expand resource attribute to all resource types by adding reskind and resclass arguments indicating the specific resource type. Change detection in HlslTypes to use these attribute arguments. Similarly add vertex number arguments to output stream attribute and a boolean indicator of input or output for tessellation patches. Add geomstream attr to detect those objects Use attribute to detect tesselation patches Removes template arg counts and startswith stirngs to identify tesslations patches and distinguish them from multisampled textures

Add setting for max vec size. Determine long vector presence using DefinitionData bit? OR Rename testing for long vecs function? Add attribute for geometry streams, produce and test errors for long vectors there. Add and test errors for > 1024 element vectors. Add vector size to error messages good test changes

Go for consistent test filename formatting. most LLVM tests have dashes, so dashes it is. Remove redundant sm68 test

Expand existing tests to different target and contexts. Add thorough testing for geometry streams and tessellation patches. Add toolong vector test. Verify that vectors that are over the maximum for 6.9 fail. Add subobjects and template classes to tests. These are unfortunately disabled because the code to make them work causes other tests to fail.

github-actions · 2025-03-03T17:00:10Z

✅ With the latest revision this PR passed the C/C++ code formatter.

Use RequireCompleteType to force specialization of templates encountered in global and other scopes where finding long vectors is necessary where possible. This populates the definitiondata which contains the base class chain needed to detect when a base class has disqualifying long vectors. It was also needed to detect when dependent types in a template class result in long vectors. Work graph node types didn't check their base classes for failures. This affects base classes with longvectors that have sub classes used for node objects which should fail for having long vector members. Respond to feedback about iterating through fields in clunky manner which got left out of the last reviewer feedback response

I guess it was about time. Should simplify some things later as well as at present and it was too easy to not do. Specifically, I was going to need to add another string check to the template instantiation code to identify longvectors. This is cleaner. Incidentally convert another feedback texture string check to use attribs. Incidentally resort the recently-added attribs to not break up the node shader attribs.

Vector types can be cached in a 2D array that has a column for lenghts 1-4. This uses the added contant to indicate the length and for the checks that confirm it isn't exceeded.

By setting the bit when the vector template is instantiated and then propagating it when members, be they standard members or base classes, the bit will be set correctly for any struct or struct-like type. For arrays, the arrays are pealed away in a utility function to get at the elements. Decided to separate the check for completeness from the check for long vectors. Even though the latter almost always requires the former, they are separate concepts and embedding the first in the second would be unexpected

Output Streams, Tessellation patches, and global variables should be complete when receiving other correctness checks. If they cannot be made complete, they should produce an error. This was omitted for various of these including non-template globals, which was fine, but it meant that redundant errors were produced for templates, but not standard globals likely just because that was what was tested. This removes that distinction and adds testing for all of the above to the existing incomplete-type.hlsl test.

alsepkow · 2025-03-06T04:53:42Z

tools/clang/lib/Sema/SemaHLSLDiagnoseTU.cpp

+        self->Diag(pPatchFnDecl->getLocation(),
+                   diag::err_hlsl_unsupported_long_vector)
+            << DXIL::kDefaultMaxVectorLength
+            << "patch constant function return type";


curious, why can't long vectors be used in patch functions? I tried to find a reference in the spec and didn't see anything. Am I missing something? Just trying to connect some dots to help learning.

We don't allow long vectors in any input or output signature elements for entry functions, as this would greatly complicate signature element handling/packing and require a design that makes sense for them.

tex3d

Finished with code review part. Haven't thoroughly reviewed all the tests yet.

tex3d · 2025-03-06T18:49:07Z

tools/clang/include/clang/Basic/DiagnosticSemaKinds.td

+def err_hlsl_unsupported_long_vector: Error<
+   "Vectors of over %0 elements in %1 are not supported">;
+def err_hlsl_vector_too_long: Error<
+   "Vectors of over %0 elements in are not supported">;


What's the difference between err_hlsl_unsupported_long_vector and err_hlsl_vector_too_long? This one looks the same, but with a missing parameter in between words - elements in are not supported. Also, I think err_hlsl_vector_too_long is unused?

tex3d · 2025-03-06T19:36:40Z

tools/clang/test/SemaHLSL/incomplete-type.hlsl

+// expected-note@+4 {{forward declaration of 'S'}} expected-note@+4 {{forward declaration of 'S'}} expected-note@+4 {{forward declaration of 'S'}}
+// expected-note@+3 {{forward declaration of 'S'}} expected-note@+3 {{forward declaration of 'S'}} expected-note@+3 {{forward declaration of 'S'}}
+// expected-note@+2 {{forward declaration of 'S'}} expected-note@+2 {{forward declaration of 'S'}} expected-note@+2 {{forward declaration of 'S'}}
+// expected-note@+1 {{forward declaration of 'S'}} expected-note@+1 {{forward declaration of 'S'}} expected-note@+1 {{forward declaration of 'S'}}


It looks like we might have much better ways to deal with this sort of duplicated note thing. Here are a few options, depending on which ones actually exist in the DXC version of the clang codebase:

Add a marker to the target line, like // #1, then refer to the marker from the place that generated the error and note, like: expected-note@#1.

This feature might be too new for the DXC codebase though.

Add a number after the expected note to indicate the count of expected identical diagnostic notes: expected-note@+1 24 {{...}}.

I'm pretty sure we have this feature in the DXC codebase.

You can also specify inexact values, like 0+, 1+, or ranges like 8-24

tex3d · 2025-03-06T20:30:43Z

tools/clang/include/clang/Basic/Attr.td

+
+def HLSLStreamOutput : InheritableAttr {
+  let Spellings = []; // No spellings!
+  let Args = [UnsignedArgument<"Vertices">];


I was confused about the "Vertices" argument at first, then I saw it was used to determine the stream type between point, line, and triangle. I guess it's fine, but wish there was a better name, like "PrimVertices" perhaps, to indicate that it indicates the primitive type by the number of vertices.

tex3d · 2025-03-06T20:32:43Z

tools/clang/include/clang/Basic/DiagnosticSemaKinds.td

@@ -7519,8 +7519,8 @@ def err_hlsl_half_load_store: Error<
  "LoadHalf and StoreHalf are not supported for min precision mode">;
 def err_hlsl_interfaces_cannot_inherit: Error<
  "interfaces cannot inherit from other types">;
-def err_hlsl_invalid_range_1_4: Error<
-  "invalid value, valid range is between 1 and 4 inclusive">;
+def err_hlsl_invalid_range_1_plus: Error<


nit, I'd prefer:

Suggested change

def err_hlsl_invalid_range_1_plus: Error<

def err_hlsl_invalid_range_1_to_max: Error<

tex3d · 2025-03-06T20:39:24Z

tools/clang/include/clang/Basic/DiagnosticSemaKinds.td

@@ -7853,6 +7851,10 @@ def err_hlsl_load_from_mesh_out_arrays: Error<
   "output arrays of a mesh shader can not be read from">;
 def err_hlsl_out_indices_array_incorrect_access: Error<
   "a vector in out indices array must be accessed as a whole">;
+def err_hlsl_unsupported_long_vector: Error<
+   "Vectors of over %0 elements in %1 are not supported">;


I can't imagine how this can ever be used with anything but 4 supplied for %0. Wouldn't it just be simpler to write that value into the diagnostic string? That way you don't have to always supply DXIL::kDefaultMaxVectorLength every time you use this diagnostic.

tex3d · 2025-03-06T21:20:08Z

tools/clang/lib/AST/HlslTypes.cpp

+    if (Attr && (Attr->getResKind() ==
+                     (unsigned)DXIL::ResourceKind::FeedbackTexture2D ||
+                 Attr->getResKind() ==
+                     (unsigned)DXIL::ResourceKind::FeedbackTexture2DArray)) {


Suggested change

if (Attr && (Attr->getResKind() ==

(unsigned)DXIL::ResourceKind::FeedbackTexture2D ||

Attr->getResKind() ==

(unsigned)DXIL::ResourceKind::FeedbackTexture2DArray)) {

if (Attr &&

DXIL::IsFeedbackTexture((DXIL::ResourceKind)Attr->getResKind())) {

tex3d · 2025-03-06T21:27:59Z

tools/clang/lib/Sema/SemaHLSL.cpp

+  // I don't think this is necessary.
+  CXXRecordDecl *Decl = vectorSpecializationType->getAsCXXRecordDecl();
+  if (GetHLSLVecSize(vectorSpecializationType) > DXIL::kDefaultMaxVectorLength)
+    Decl->setHasHLSLLongVector();
+


Presumably this is not necessary because Sema::InstantiateClass will set the property. Shouldn't this code just be deleted?

tex3d · 2025-03-06T21:36:05Z

tools/clang/lib/AST/ASTContextHLSL.cpp

+  typeDeclBuilder.getRecordDecl()->addAttr(HLSLResourceAttr::CreateImplicit(
+      context, (unsigned)DXIL::ResourceKind::CBuffer,
+      (unsigned)DXIL::ResourceClass::CBuffer));


I think we should be changing this depending on bTBuf to ResourceClass::SRV and ResourceKind::TBuffer. That has implications for locations where we need to match TextureBuffer type by this attribute as well.

Suggested change

typeDeclBuilder.getRecordDecl()->addAttr(HLSLResourceAttr::CreateImplicit(

context, (unsigned)DXIL::ResourceKind::CBuffer,

(unsigned)DXIL::ResourceClass::CBuffer));

typeDeclBuilder.getRecordDecl()->addAttr(HLSLResourceAttr::CreateImplicit(

context,

(unsigned)(bTBuf ? DXIL::ResourceKind::TBuffer

: DXIL::ResourceKind::CBuffer),

(unsigned)(bTBuf ? DXIL::ResourceClass::SRV

: DXIL::ResourceClass::CBuffer)));

tex3d · 2025-03-06T21:39:38Z

tools/clang/lib/Sema/SemaHLSLDiagnoseTU.cpp

+        self->Diag(pPatchFnDecl->getLocation(),
+                   diag::err_hlsl_unsupported_long_vector)
+            << DXIL::kDefaultMaxVectorLength
+            << "patch constant function return type";


We don't allow long vectors in any input or output signature elements for entry functions, as this would greatly complicate signature element handling/packing and require a design that makes sense for them.

tex3d · 2025-03-07T01:14:38Z

tools/clang/lib/Sema/SemaHLSL.cpp

@@ -16268,6 +16383,18 @@ void DiagnoseEntry(Sema &S, FunctionDecl *FD) {
    return;
  }

+  // Check general parameter characteristics
+  // Would be nice to check for resources here as they crash the compiler now.


Is there an issue for this?

pow2clk added 2 commits February 17, 2025 21:49

Produce errors for long vectors in invalid contexts

e010223

Disallow long vectors, and arrays or structs containing long vectors in cbuffers, entry functions, node records, tessellation patchs, or special intrinsic parameters with user-defined struct parameters.

pow2clk requested a review from a team as a code owner February 18, 2025 16:20

fix assert for tesselation patch template args

cd72abe

This got lost somewhere

llvm-beanz self-assigned this Feb 18, 2025

damyanp assigned tex3d Feb 18, 2025

alsepkow reviewed Feb 18, 2025

View reviewed changes

alsepkow reviewed Feb 19, 2025

View reviewed changes

llvm-beanz reviewed Feb 19, 2025

View reviewed changes

tex3d reviewed Feb 19, 2025

View reviewed changes

tools/clang/lib/Sema/SemaHLSL.cpp Outdated Show resolved Hide resolved

llvm-beanz reviewed Feb 19, 2025

View reviewed changes

tex3d reviewed Feb 19, 2025

View reviewed changes

tools/clang/lib/Sema/SemaHLSL.cpp Outdated Show resolved Hide resolved

tex3d reviewed Feb 19, 2025

View reviewed changes

tools/clang/include/clang/Basic/Attr.td Outdated Show resolved Hide resolved

tex3d mentioned this pull request Feb 20, 2025

Disallow structs, arrays, and overwide vectors from typed buffers #7130

Merged

pow2clk commented Feb 20, 2025

View reviewed changes

tex3d mentioned this pull request Feb 25, 2025

Allow native vectors for LLVM operations #7155

Open

pow2clk added 5 commits March 3, 2025 09:40

Merge remote-tracking branch 'refs/remotes/origin/main' into longvec_…

4d5c2a2

…decls_pr

Reaname and consolidate longvecs tests

76dde0d

Go for consistent test filename formatting. most LLVM tests have dashes, so dashes it is. Remove redundant sm68 test

pow2clk and others added 7 commits March 3, 2025 13:00

clang-format

fb6538e

chore: autopublish 2025-03-05T20:50:11Z

466bb14

Use constant vector limit value for cached types

20c2609

Vector types can be cached in a 2D array that has a column for lenghts 1-4. This uses the added contant to indicate the length and for the checks that confirm it isn't exceeded.

alsepkow reviewed Mar 6, 2025

View reviewed changes

tex3d reviewed Mar 7, 2025

View reviewed changes

damyanp assigned pow2clk and unassigned tex3d Mar 7, 2025

	bool HasLongVecs(const clang::QualType &qt);
	bool ContainsLongVecSubObject(const clang::QualType &);

		@@ -0,0 +1,132 @@
		// RUN: %dxc -DTYPE=float -DNUM=7 -T ps_6_9 -verify %s

	def err_hlsl_invalid_range_1_plus: Error<
	def err_hlsl_invalid_range_1_to_max: Error<

[SM6.9] Allow native vectors longer than 4 #7143

Are you sure you want to change the base?

[SM6.9] Allow native vectors longer than 4 #7143

Conversation

pow2clk commented Feb 18, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pow2clk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Mar 3, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tex3d left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Mar 3, 2025 •

edited

Loading