beanz added inline comments.
================
Comment at: clang/include/clang/AST/Attr.h:193
+class HLSLAnnotationAttr : public InheritableAttr {
+protected:
----------------
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...
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D131625/new/
https://reviews.llvm.org/D131625
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
