[PATCH] D76384: Move FPFeatures from BinaryOperator bitfields to Trailing storage
Melanie Blower via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Wed Mar 25 09:43:31 PDT 2020
mibintc marked an inline comment as done.
mibintc added inline comments.
================
Comment at: clang/include/clang/AST/Expr.h:3465
+ SubExprs[RHS] = rhs;
+ hasFPFeatures = true;
+ isCompoundAssign = 1;
----------------
rjmccall wrote:
> Okay, so this is *always* adding trailing storage. Is there a common value for `FPOptions` — something that corresponds to default settings, for example — that we could use to avoid needing storage in the common case?
>
> Also, it would be useful to extract a function somewhere that you can use in all of these places for consistency, maybe something like this on `FPOptions`:
>
> ```
> /// Does this FPOptions require trailing storage when stored in various AST nodes,
> /// or can it be recreated using `defaultWithoutTrailingStorage`?
> bool requiresTrailingStorage() const { return *this == defaultWithoutTrailingStorage(); }
>
> /// Return the default value of FPOptions that's used when trailing storage isn't required.
> static FPOptions defaultWithoutTrailingStorage() { ... }
> ```
The reason I set hasFPFeatures to True in this revision is because in the previous review you asked me to make it purely a representational change and "add stuff about whether there is a pragma in a separate patch". The stuff I had in the previous version was smarter about creating trailing storage, it only created trailing storage when the pragma was in effect. I envirsioned that the evolution would accept something that always created the FPOptions in trailing storage, and in the 2nd generation would adopt the more thrifty way of creating trailing storage.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D76384/new/
https://reviews.llvm.org/D76384
More information about the cfe-commits
mailing list