[PATCH] D113107: Support of expression granularity for _Float16.

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Supporting the lowering in the backend is sensible in order to support `-fexcess-precision=16`, because I agree that the most reasonable IR output in that configuration is to simply generate `half` operations.  But under `-fexcess-precision=32`, I do not want the frontend to be in the business of recognizing cases where promoted emission is unnecessary, because that is just a lot of extra complexity for something that's already fairly special-case logic; among other things, it will tend to hide bugs.

> I don't understand, how can we check the missed cases if the promotion was done in FE?

You simply test that you do not see any unpromoted operations coming out of the frontend.  Any operation emitted on `half` (except conversions to and from other types) is probably a missed opportunity to be doing promoted emission.  For example, if we saw that `x += y + z` performed a `half` operation for the final addition, it would suggest that we had a bug in the emission of `+=`, not just because we were emitting a `half` operation but because we were likely failing to propagate promoted emission into the RHS of the operator, i.e. that we were introducing an unnecessary truncation there.

Of course, knowing that we aren't doing operations on `half` doesn't mean we aren't doing unnecessary truncations explicitly, so we still need to be testing such cases.  But it's an easy way to see bugs when simply scanning the IR generated for a program.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107