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

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.


================
Comment at: clang/include/clang/AST/Attr.h:193
 
+class HLSLAnnotationAttr : public InheritableAttr {
+protected:
----------------
beanz wrote:
> aaron.ballman wrote:
> > beanz wrote:
> > > 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.
> > > 
> > Oh, thank you for the explanation!
> > 
> > > 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.
> > 
> > Well that should be fun if you have code that cares about the address of the function, depending on which address you happen to get. But you don't allow pointers IIRC, so maybe you're "safe"?
> I _think_ taking the address of the function should consistently give the address of the mangled function since the AST will resolve using C++ mangling rules. I hope that would be the expected behavior even if we exposed pointers in the future since the `void(void)` entry should only ever be the hardware start point.
> 
> I'm sure I'm wrong about this and will regret this speculation in the future...
Keep in mind that we have things like `__builtin_frame_address()` which exposes "this function" and "calling function" to the caller in ways that may be surprising. That said, if someone is using those kinds of tricks to inspect the identity of a function, I'm not certain how sympathetic I am to their plight in this case.


================
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_semantic_annotation : Error<"semantic annotations must be present for all parameters of an entry function or patch constant function">;
 
----------------
I have no idea how close to the 80 col limit I got this, but we do mostly try to ensure diagnostics don't go too far over the 80 col limit (we're more lax in .td files because clang-format sometimes destroys the formatting rather than help it).


================
Comment at: clang/lib/Sema/SemaDecl.cpp:11876
+    if (!Param->hasAttr<HLSLAnnotationAttr>()) {
+      // FIXME: Handle struct parameters where annotations are on struct fields.
+      Diag(FD->getLocation(), diag::err_hlsl_missing_semantic_annotation);
----------------
What about checking for the function return type?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131625