================
@@ -89,37 +88,178 @@ bool RootSignatureParser::parseDescriptorTableClause() {
           CurToken.TokKind == TokenKind::kw_UAV ||
           CurToken.TokKind == TokenKind::kw_Sampler) &&
          "Expects to only be invoked starting at given keyword");
+  TokenKind ParamKind = CurToken.TokKind; // retain for diagnostics
 
   DescriptorTableClause Clause;
-  switch (CurToken.TokKind) {
+  TokenKind ExpectedRegister;
+  switch (ParamKind) {
   default:
     llvm_unreachable("Switch for consumed token was not provided");
   case TokenKind::kw_CBV:
     Clause.Type = ClauseType::CBuffer;
+    ExpectedRegister = TokenKind::bReg;
     break;
   case TokenKind::kw_SRV:
     Clause.Type = ClauseType::SRV;
+    ExpectedRegister = TokenKind::tReg;
     break;
   case TokenKind::kw_UAV:
     Clause.Type = ClauseType::UAV;
+    ExpectedRegister = TokenKind::uReg;
     break;
   case TokenKind::kw_Sampler:
     Clause.Type = ClauseType::Sampler;
+    ExpectedRegister = TokenKind::sReg;
     break;
   }
 
   if (consumeExpectedToken(TokenKind::pu_l_paren, diag::err_expected_after,
-                           CurToken.TokKind))
+                           ParamKind))
     return true;
 
-  if (consumeExpectedToken(TokenKind::pu_r_paren, diag::err_expected_after,
-                           CurToken.TokKind))
+  llvm::SmallDenseMap<TokenKind, ParamType> Params = {
----------------
llvm-beanz wrote:

I'm a bit torn. The pattern used in Clang for things that can be parsed in 
arbitrary order (like attributes) might be a bit overkill. Clang fully 
separates parsing from semantic analysis, so it parses all your attributes 
separate from converting them into AST nodes and attaching them to the proper 
parent. 

The structure-of-array approach storing all tokens has some scalability 
concerns to me, and I'm not sure the genericness-gives benefit. Similarly I'm 
not sure the map approach as implemented is the right approach.

My gut feeling is that we probably shouldn't use the same implementation for 
parsing descriptor table parameters and sampler parameters.

I think a parameters structure for 6 parameters with either bools (which could 
be uint32_t bitfield members) or optionals to signal if they are seen makes 
sense. I suspect if they're mandatory should be something we know from context 
and don't need additional tracking of.

https://github.com/llvm/llvm-project/pull/133800
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to