[PATCH] D72841: [RFC] Add support for pragma float_control, to control precision and exception behavior at the source level

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In D72841#1912416 <https://reviews.llvm.org/D72841#1912416>, @mibintc wrote:

> In D72841#1911330 <https://reviews.llvm.org/D72841#1911330>, @rjmccall wrote:
>
> > In D72841#1908084 <https://reviews.llvm.org/D72841#1908084>, @mibintc wrote:
> >
> > > @rjmccall suggested that I needed to remove FPOptions from the Stmt class since the sizeof assertion failed. I moved that information into the relevant expression nodes and fixed a few small things that I didn't like in the previous version.
> >
> >
> > You only need to do this for the expression nodes where it causes an overflow in the size of the bit-field; I don't think you're overflowing the capacity of UnaryOperatorBitfields, for example.
>
>
> I added unsigned FPFeatures : 14; to class UnaryOperatorBitfields but I encountered the same assertion failure in the Stmt constructor, In constructor ‘clang::Stmt::Stmt(clang::Stmt::StmtClass)’:
>  /iusers/sandbox/pragma-ws/llvm-project/clang/include/clang/AST/Stmt.h:1095:5: error: static assertion failed: changing bitfields changed sizeof(Stmt)
>
>   static_assert(sizeof(*this) <= 8


Oh, okay.  It's actually pretty unfortunate that we need to increase the memory use of every UnaryOperator, BinaryOperator, and CallExpr in the AST just in case these pragmas are in use.  Most instances of these expressions provably have nothing to do with floating-point, and in practice the pragmas are very rarely used.

I mentioned up-thread that it would be nice to make serialized AST actually agnostic about the basic language settings.  That would require us to track not just the active option set, but what overrides were actually in place when parsing any given expression; we could then merge the two pretty easily in IRGen.   (We could represent this with masks: we could then merge the information by taking the default-settings mask, bitwise-and'ing with the override mask to clear any values that will be overridden, and bitwise-or'ing the override values on top.)  But if we did that, then it would be easy for us to identify when creating an AST node that no overrides are in effect; that would let us just store a single flag in the class indicating whether there were overrides, then use trailing storage for the actual overrides if present.  This would relieve almost all of the pressure to keep the storage size down.

We could take it a step further by trying to recognize when building certain AST nodes that they're not floating-point operations and just building them with no overrides.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72841