[cfe-dev] Design of FPOptions

[Sam McCall via cfe-dev]

I don't have a lot to add here but wanted to say thanks for thinking deeply
about this.
Us trying to squeeze into 7 bits was a pretty shallow+short-term view that
might make sense if FP was fairly static. Fortunately the immediate need
for that has passed (thanks Roman!)

Growing in #bits suggested that TrailingObjects makes sense, and growing in
applicable scope means even that might not be enough (if it's used in more
and more nodes). So I guess this was bound to come up, and solution #4
sounds like the most scalable answer, though I don't know the domain well.

On Thu, Mar 12, 2020 at 7:24 AM Serge Pavlov <sepavloff at gmail.com> wrote:

> 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/20200317/1f1b12a2/attachment.html>