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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
