[cfe-dev] Changing semantics of __fp16

[Richard Sandiford via cfe-dev]

Hi,

Thanks for the feedback.  I think there are really two independent aspects to the proposal:

(1) Which 16-bit float types should change behaviour?
(2) When should they change behaviour?

For (1) the choices are:

(1a) Change float16_t and __fp16 [Approach A in Sjoerd's email]
(1b) Change float16_t only [Approach B]

For (2) the choices can be divided up as:

(2a) Make the new behaviour opt-in
(2b) Make the new behaviour opt-out
(2c) Make the new behaviour unconditional

That gives 6 combinations in total.  I think the feedback so far is that (1b) + (2c) is preferable to (1a) + (2c), which is just the kind of thing we were hoping for from this thread, thanks.  In addition to that, do you have any thoughts about the other 4 combinations?

Personally I was wary of (1b) because, as you say, it changes a typedef provided by the ACLE.  This is an ABI break, in the sense that it changes the mangling of a C++ function (F) that takes float16_t arguments.  Definitions of F compiled before the change won't link against uses of F compiled after the change, and definitions of F compiled after the change won't link against uses of F compiled before the change.

>From that point of view, (2a) seems like the most conservative option: existing binaries remain link-compatible with new binaries, and existing float16_t and __fp16 code keep their current behaviour.  Other targets that have adopted __fp16 remain unaffected.

(1a) + (2b) is less conservative: existing binaries remain link-compatible with new binaries, but projects that rely on the existing float16_t and __fp16 behaviour would need to be adjusted for newer compilers.  Perhaps there's a weak analogy here with bumping the default -std= option.

This is only a high-level classification.  The opt-ins or opt-outs could be controlled in various ways.  Possibilities include:

  *   a new command-line option
  *   a new pragma (for (1a))
  *   a special macro that needs to be defined before including the ACLE header files (for (1b))

The defaults could depend on the target, if that seemed preferable.

When compiling a function F that uses float16_t (perhaps internally), the float16_t semantics effectively become a property of F's definition.  Mixing a definition of F with the old float16_t semantics and a definition of F with new float16_t semantics would break the One Definition Rule.  (2a) and (2b) make it easier to avoid ODR violations, (2c) would effectively force the user to recompile affected .os.

Thanks, and sorry for the long email.

Richard

________________________________
From: Steve (Numerics) Canon <scanon at apple.com>
Sent: 10 December 2020 16:18
To: Sjoerd Meijer <Sjoerd.Meijer at arm.com>
Cc: cfe-dev at lists.llvm.org Developers <cfe-dev at lists.llvm.org>; Richard Sandiford <Richard.Sandiford at arm.com>
Subject: Re: [cfe-dev] Changing semantics of __fp16

Hi —

Silently changing the semantics of __fp16 (Approach A) so that existing programs suddenly get different (and in many cases, worse) results seems quite problematic to me.

Approach B is _also_ deeply flawed, however, as it violates the ACLE documentation for float16_t:

> If the __fp16 type is defined, float16_t is defined as an alias for it.

I have a slight preference for approach B, because it only effects people using float16_t, and not users of __fp16, and allows them the escape valve of switching to using __fp16 explicitly if they need the old behavior.

– Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20201211/af1dbbf0/attachment-0001.html>