[cfe-dev] [RFC] implementation of _Float16

[Hal Finkel via cfe-dev]

On 05/11/2017 05:54 PM, Tim Northover wrote:
> On 10 May 2017 at 09:39, Hal Finkel via cfe-dev <cfe-dev at lists.llvm.org> wrote:
>> By "when required", do you mean when the result would be the same as if the
>> operation had been performed in single precision? If so, then no, we need
>> different semantics.
> I don't follow here. I've discussed this before (with Steve Canon, so
> if he says anything that contradicts me, ignore me), and I was
> convinced that all of LLVM's primitive operations have the same
> semantics as half as when promoted to float and then truncated again
> (including sqrt, but not fma I believe).

That's what's been asserted here as well. The question is: If we're 
going to want a type that represents half precision without the implied 
extend/truncate operations, do we a) Introduce a new type that is 
"really" a half or b) change half not to imply the extend/truncate and 
then autoupgrade?

  -Hal

>
> So as far as I know the situation right now is that we miscompile
> @llvm.fma.f16 with an extra fpext/fptrunc. That could be a problem if
> Clang emits that for __fp16, but I haven't managed to make it do so
> yet ("fp contract" seems to give a fmuladd with correct promotions
> etc).
>
> Other than that, transcendentals are pattern-matched so shouldn't
> cause compatibility issues.
>
> Do you have any more specific worries?
>
> Cheers.
>
> Tim.

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory