Page MenuHomePhabricator

R600: support extension from fp16 to f64
ClosedPublic

Authored by t.p.northover on Jul 17 2014, 5:39 AM.

Details

Reviewers
arsenm
Summary

Hi,

I'm in the process of reworking how we handle the __fp16 type slightly. I have larger goals, but the most important immediate one is to perform extensions and truncations in one step so that this C code has IEEE-sensible semantics:

void my_round(double in, __fp16 *out) { *out = in; }

Now, I *think* this is fairly academic as far as OpenCL is concerned (you have to use the vload_half/vstore_half functions to access __fp16 at all times), but I'd like to minimise breakage as far as possible anyway.

As part of this I've made the @llvm.convert.from.fp16 and @llvm.convert.to.fp16 intrinsics polymorphic, and would like to add support for f64 variants in as many places as possible.

For R600, it looks like there is no single-step truncation, or support for intrinsics. This means the truncation will always fail to compile, but the attached patch implements extension correctly by splitting it into two operations: f16 -> f32 -> f64.

Are you happy for me to commit the change?

Cheers.

Tim.

Diff Detail

Event Timeline

t.p.northover retitled this revision from to R600: support extension from fp16 to f64.
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).
arsenm accepted this revision.Jul 17 2014, 9:35 AM
arsenm added a reviewer: arsenm.
arsenm added a subscriber: arsenm.

LGTM. This should probably go in AMDGPUISelLowering, but doesn't really matter since f64 is currently totally broken on Evergreen

This revision is now accepted and ready to land.Jul 17 2014, 9:35 AM
t.p.northover closed this revision.Jul 18 2014, 1:52 AM

Thanks Matt. I've moved it to AMDGPUISelLowering for when wider f64 support does come along and committed it in r213357.

Tim.