[cfe-dev] Design of FPOptions

[Serge Pavlov via cfe-dev]

Hi all,

There are development efforts aimed at reducing space occupied by the field
FPFeatures (https://reviews.llvm.org/D72841). The expected result is
reduction of the FPFeatures size from 8 bits to 7, so it is really a battle
for bit. I have concern that such work can impact readability and
maintainability of the code and would like to discuss alternative ways.

*Background*

There are two main things that form background of the problem.

First, operations that involve floating point arguments need to specify
floating point environment. The latter is comprised of bits of hardware
state registers  (rounding direction, denormals behavior, exception mask)
and options and hints provided by user to compiler (whether NANs may occur,
shall sign of zero be conserved, may exceptions be ignored). The list of
relevant options was discussed in
http://lists.llvm.org/pipermail/llvm-dev/2020-January/138652.html. It is
convenient to collect all aspects of the FP environment into one object,
this is what class FPOptions does. Now this class contains only few
attributes but in https://reviews.llvm.org/D72841 an attempt was made to
extend it in right direction.

Second, the Clang internal representation (AST) was implemented to be as
compact as possible. The dark side of this principle is inconvenient class
organization and diffuse class boundaries, - derived classes keep their
states in parent class fields, which are fixed in size. FP environment now
is represented by a field in the class BinaryOperatorBitfields and is only
8 bits in size.

*The problem*

8 bits is too few to keep all FP related state and options. So in
https://reviews.llvm.org/D72841 FPOptions was moved out of
BinaryOperatorBitfields and made a field in classes UnaryOperator,
BinaryOperator, CallExpr and CXXOperatorCallExpr. It is a step in right
direction as, for example, now UnaryOperator does not have FPOption.

This change however resulted in that every instance of BinaryOperator,
CallExpr and other now increase in size. To reduce the space refactoring of
https://reviews.llvm.org/D72841 was started.

Current support of FP environment in clang is weak, ongoing development in
this direction will eventually increase size required for FP state and
options and increase number of AST nodes that require knowledge of FP
environment (these could be FloatingLiteral, InitListExpr,
CXXDefaultArgExpr and some other). We must elaborate solution that allow
future extensions without massive changes.

*Possible solutions*

1. Consider memory consumption as inevitable evil and add FPOtions to every
node where it is needed.

2. Add FPOptions to subclasses, for example FloatingUnaryOperator and
similar. It however would swamp class hierarchy with duplicates and make
handling AST more complex, as we use static polymorphism, not dynamic.

3. Use trailing objects. While this way is natural when the size of
additional information is variable, using trailing objects to keep just
some fields of an object is inconvenient.

4. Keep FPOptions is a special node, say FloatingPointRegionStmt. As now FP
environment can be modified only at block and function level, actually the
same FPOption is replicated to all nodes of that block. This
FloatingPointRegionStmt would be similar to nodes like ExprWithCleanups, as
it would represent a notion rather than source code construct. We also
could embed FPOptions directly into CompoundStmt, but we must also provide
similar facility at least for initializers and default arguments.

I am inclined to the solution 4, as it reduces size consumption and at the
same time does not limit implementation of FPOptions.

Thanks,
--Serge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200312/34706b43/attachment-0001.html>