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

Zahira Ammarguellat via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Jun 22 11:17:55 PDT 2022

zahiraam added a comment.

In D113107#3601873 <https://reviews.llvm.org/D113107#3601873>, @rjmccall wrote:

> 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.

Incidentally this little example here is not working with this patch. I will add code to fix it. It is now generating an fadd half.
Do we want to add an -fexcess-precision option?



More information about the cfe-commits mailing list