[PATCH] D53738: [Fixed Point Arithmetic] Fixed Point Addition

Wed Oct 31 21:45:11 PDT 2018

rjmccall added a comment.

In https://reviews.llvm.org/D53738#1281894, @ebevhan wrote:

> In https://reviews.llvm.org/D53738#1281332, @rjmccall wrote:
>
> > Well, maybe the cleanest solution would be to actually fold `CompoundAssignOperator` back into `BinaryOperator` and just allow `BinaryOperator` to optionally store information about the intermediate type of the computation and how the operands need to be promoted.  That information could be elided in the common cases where it's trivial, of course.
>
>
> That sounds like a fairly hefty refactor. Also, doing the fold would put the extra QualType info from CAO into BO, sure, but this cannot work for the full-precision case since we can't represent those with QualTypes. The information for the full precision 'type' would have to be stored separately anyway.

Well, it could be passed around through most code as some sort of abstractly-represented intermediate "type" which could be either a QualType or a fixed-point semantics.

> It might just be easier to store the full-precision info in BO directly. BO might be too common to warrant the size increase, though. FixedPointSemantics can probably be optimized to only take 32 bits.

What you can definitely do is store a bit in BO saying that there's extra storage for the intermediate "type".

>> The infinite-precision rule here is still internal to an individual operator, right?  The standard's not trying to say that we should evaluate `x + y < z` by doing a comparison as if all the operands were individually infinite-precision?
> 
> Correct, the result of the computation is 'implicitly converted' back to the result type after the operation is performed. The type of the expression will always be the result type, never the full precision type.

Okay, good.

> As a side note, comparisons are still a bit up in the air. I don't think we came to a conclusion on whether they should be done in full precision or bitwise. The spec isn't clear.

...bitwise?

Repository:
  rC Clang

https://reviews.llvm.org/D53738