[PATCH] D50119: Compiler support for P1144R0 "__is_trivially_relocatable(T)"

[John McCall via Phabricator via cfe-commits]

rjmccall added a reviewer: ahatanak.
rjmccall added inline comments.


================
Comment at: include/clang/AST/DeclCXX.h:482
+    /// and a defaulted destructor.
+    unsigned IsNaturallyTriviallyRelocatable : 1;
+
----------------
Quuxplusone wrote:
> erichkeane wrote:
> > Quuxplusone wrote:
> > > erichkeane wrote:
> > > > Typically we'd have this calculated when requested rather than stored. I suspect using a bit for something like this isn't going to be terribly acceptable.
> > > You know better than I do; but I'm also not sure how to calculate it on request.
> > You'll end up just recursively walking the CXXRecordDecl upon application of the type trait, and need to check the things that make it NOT trivially relocatable.
> > 
> > I think it also extensively simplifies this patch, since none of the CXXRecordDecl functions are required (just the type-trait emission).
> @erichkeane: I tried to follow this advice tonight, but I can't find any other type trait in Clang that is implemented the way you described. Every other type trait seems to be implemented in exactly the way I did it: isPolymorphic, isAbstract, isStandardLayoutType, isTrivialType, isAggregateType, hasTrivialDefaultConstructor... they all seem to occupy a bit in CXXRecordDecl. None of them seem to be computed by walking the `fields()` of a CXXRecordDecl on the fly — and that makes sense to me, because that would be an arbitrarily slow operation, whereas keeping the bit is O(1) no matter how many times the result is asked for.
> If calculating traits on request is "typical," can you point me to somewhere in Clang where it happens, so that I can try to copy how they do it?
Most of the other unary traits actually have to be computed just for at least some aspect of normal compiler operation, but that's not true of this, so I can understand the desire to avoid burdening the logic.  In this case, though, I think it's fine because it's pretty trivial to collect this when we're already collecting almost all of the relevant information as part of the trivial-ABI calculation.  In fact, it meshes well with some things we've thought about doing for some non-standard sources of non-triviality; CC'ing Akira Hatanaka for his thoughts.


Repository:
  rC Clang

https://reviews.llvm.org/D50119