[PATCH] D126907: Deferred Concept Instantiation Implementation Take 2

Erich Keane via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Jun 30 06:16:57 PDT 2022


erichkeane added inline comments.


================
Comment at: clang/include/clang/AST/Decl.h:1944-1948
+  /// For non-templates this value will be NULL, unless this non-template
+  /// function declaration was declared directly inside of a function template,
+  /// in which case this will have a pointer to a FunctionDecl, stored in the
+  /// NamedDecl. For function declarations that describe a function template,
+  /// this will be a pointer to a FunctionTemplateDecl, stored in the NamedDecl.
----------------
ChuanqiXu wrote:
> erichkeane wrote:
> > ChuanqiXu wrote:
> > > Could we give a new abstract like `XXXInfo` to replace `NamedDecl*` here? The NamedDecl* covers a lot of things. It looks more consistent.
> > All of those 'Info' types contain significantly more information, which we really don't have a need for here.  Basically all this patch is doing is using the FunctionTemplateDecl* that was already in the list and generalizing it a bit.  AND unfortunately, the only commonality between FunctionTemplateDecl and FunctionDecl is NamedDecl.  
> > 
> > So any type we would use would end up causing an additional allocation here, and make its use require us to unpack it :/
> > 
> > I guess what I'm saying, is I'm not sure what that would look like in a way that wouldn't make this worse.  Do you have an idea you could share that would improve that?  
> > 
> > 
> My idea would be something like:
> 
> ```C++
> llvm::PointerUnion<FunctionDecl *, FunctionTemplateDecl*, MemberSpecializationInfo *,
>                      FunctionTemplateSpecializationInfo *,
> ```
> 
> > So any type we would use would end up causing an additional allocation here, and make its use require us to unpack it :/
> 
> This is a union so it wouldn't cause additional allocations?
> 
I tried doing FunctionDecl and FunctionTemplateDecl at one point, but we endd up running out of bits for the pointer-union to work on 32 bit builds.  Otherwise I would have done that.

I misunderstood the 'Info' thing and thought you wanted a new wrapper type (an 'Info' type), which would need to be allocated and contain just a pointer, which is why I was thinking about needing allocations.


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

https://reviews.llvm.org/D126907



More information about the cfe-commits mailing list