[PATCH] D131625: [HLSL] Entry functions require param annotation

Chris Bieneman via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Aug 19 08:31:43 PDT 2022


beanz added inline comments.


================
Comment at: clang/include/clang/AST/Attr.h:193
 
+class HLSLAnnotationAttr : public InheritableAttr {
+protected:
----------------
aaron.ballman wrote:
> Is this intended to be used only for parameters (that's how I read the summary for the patch)? If so, why is this not inheriting from `InheritableParamAttr`?
Sadly these attributes are valid in places that aren’t parameters. For example, they can be applied on the members of a struct. When specifying an HLSL entry we require semantics for all scalar variables in the signature so that the we can match up the parameters from driver and user-provided values, but the parameters can be scalars or user defined structs. For example:

```
struct Pupper {
  int Legs : SomeAnnotation;
  int Ears : SomeOtherAnnotation;
}
...
void main(Pupper P) {...} // valid as an entry
```

We also allow these annotations (and require them) on return types for entry functions:

```
int main(...) : SomeAnnotation {...}
```

Where this all gets really special is that entry functions as passed to drivers have a `void(void)` signature, but entry functions with the source-specified signature can be called.

I'm trying to handle those cases in D131203 by generating the user-written function as is with C++ mangling, and generating a non-mangled `void(void)` wrapper that calls the underlying function after populating the annotation values. It is an incomplete implementation, but a starting point.



================
Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:11635
 def err_hlsl_attribute_param_mismatch : Error<"%0 attribute parameters do not match the previous declaration">;
+def err_hlsl_missing_parameter_annotation : Error<"entry function parameter %0 missing annotation">;
 
----------------
aaron.ballman wrote:
> Will users know how to fix the issue when they get this diagnostic? "missing annotation" sounds like "slap any old annotation on there, it'll be fine".
I should probably make this closer to our existing diagnostic: "Semantic must be defined for all parameters of an entry function or patch constant function."


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D131625/new/

https://reviews.llvm.org/D131625



More information about the cfe-commits mailing list