This is an archive of the discontinued LLVM Phabricator instance.

[CodeGen] Convert double -> __fp16 in one step.
ClosedPublic

Authored by ab on Jul 21 2014, 4:36 AM.

Details

Summary

Hi,

The attached patch changes Clang so that for types bigger than float, instead of converting to fp16 via the sequence "InTy -> float -> fp16", we perform conversions in just one step. This avoids the double rounding which potentially changes results from a natural IEEE-754 operation.

There are potential problems, but I believe the benefits outweigh them:

  • It's a change in semantics. I believe it's compatible with the major standards though (OpenCL requires accesses go via a builtin; n1833 for C would *demand* this change, from my reading of it).
  • It means double -> __fp16 conversion will fail on x86 and v7 ARM CPUs for now. Specifically, we will generate a libcall which isn't actually widespread (or probably implemented anywhere). I think this is preferable to the status-quo of producing a possibly incorrect result though.

Longer term, I'd like to improve the codegen here to use real fpext/fptrunc operations and remove many of the special cases for half. Unfortunately the LLVM CodeGen isn't up to this change yet, so I've just extended the use of the @llvm.convert.to.fp16 intrinsic.

So, is it OK to change this?

Cheers.

Tim.

Diff Detail

Event Timeline

t.p.northover retitled this revision from to CodeGen: convert double -> __fp16 in one step.
t.p.northover updated this object.
t.p.northover edited the test plan for this revision. (Show Details)
t.p.northover added a subscriber: Unknown Object (MLST).

Ping?

Cheers.

Tim.

ab commandeered this revision.Feb 11 2015, 4:43 PM
ab added a reviewer: t.p.northover.
ab updated this revision to Diff 19797.Feb 11 2015, 4:49 PM
ab removed a reviewer: t.p.northover.
ab added a subscriber: t.p.northover.

Hi all,

Ping for Tim's patch!

I rebased it and added the one-step __fp16->double conversion, which, while not necessary for correctness, is nice to have (if only for symmetry.)
We're still missing the libcalls, so this will break the conversions from/to double. However, I agree with Tim in that it's better than incorrect results.

-Ahmed

Hi Ahmed,

The patch looks good to me. However, I don't think I am knowledgeable enough to give the final approval. So, somebody else should review this patch.

My personal opinion (for what is worth..) is that this is the correct approach. On X86, I am not particularly worried about the extra runtime libcalls which could be generated for double-to-half conversions. Also, (as you already know) the target independent legalizer now knows how to split a double-to-half conversion into the sequence 'double-to-float' plus 'float-to-half' (only under fast-math).

24 February 2015 at 10:47, Ahmed Bougacha <ahmed.bougacha@gmail.com> wrote:

Ping!

I still think this is the right approach too. A 2-step conversion is
pretty much impossible to justify logically; users who really still
want it can force that behaviour by casting to float first.

Cheers.

Tim.

ab retitled this revision from CodeGen: convert double -> __fp16 in one step to [CodeGen] Convert double -> __fp16 in one step..Mar 2 2015, 9:59 AM

Ping again!

(Andrea & Tim, thanks for the comments)

-Ahmed

ab added a comment.Mar 9 2015, 1:38 PM

Monday ping!

Ping!

Tentatively adding Oliver as a reviewer =)

-Ahmed

ab accepted this revision.Mar 23 2015, 10:58 AM
ab added a reviewer: ab.

Reviewed as part of http://reviews.llvm.org/D8367

This revision is now accepted and ready to land.Mar 23 2015, 10:58 AM
ab closed this revision.Mar 23 2015, 10:59 AM

.. and committed in r232968.

-Ahmed