ebevhan added a comment. 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. Or did you mean to make a subclass of that new BinaryOperator for the full precision case, and store the full precision info there? 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. > 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. 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. 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
