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? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D113107/new/ https://reviews.llvm.org/D113107 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
