[PATCH] ARM half-precision floating point, 3/8 (target hooks)

[Paolo Bonzini]

> It would be nice if we could do that.  I imagine that now that
> half-precision is in the IEEE standard, it's going to be picked up by
> other targets and may make it into future versions of the C/C++ language
> standards as well (although maybe not with the exact semantics that I've
> implemented here).

Yes -- and if the semantics change in the standards, ARM is probably
going to adjust.  Having at least one compiler "attempt" to provide a
target-independent extension is also good from a standards body point of
view.

> I thought that the language-level issues were quite
> straightforward, both conceptually and implementation-wise.
> 
> So if we did add HFmode knowledge to
> the compiler front end, we'd still need some sort of target hook to
> control whether it's supported at all by the back end.

There are two such knobs already in place.  One is simply
register_builtin_type, as you use it in arm_init_fp16_builtins; this
makes it harder to "casually" use HFmode if it is not supported.

The other is the targetm.scalar_mode_supported_p hook, which is used to
handle something like

  typedef float fp16 __attribute__((mode (HF)));

Right now, this would fail even for ARM, but this is not something you
need to fix now.

> Anyway, I could rework this part of the implementation if there's
> consensus that it's the right thing to do, that the semantics as
> currently implemented for ARM are useful in general, etc.

Yes, that's right, but I think that the semantics are quite nice and
unambiguous from what I saw in the code.  It is feasible to foresee the
lifting of the restrictions on parameter passing and returning (after
all you can pass and return char, and all that does is inserting
coercions on the callee resp. caller side), but that's easy to do in the
future and does not break backwards compatibility.

There is one point that I did not really understand, which is the
convert_to_type hook, since you are then implementing the same semantics
again in the RTL patterns for fix_trunchfsi and floathfsi2.  Everything
else could simply be inlined at the point where you call the target hook.

> I'd have to
> give it some thought to come up with a new design for the front end/back
> end interface, though -- so I'd prefer to get some guidance that it's
> really the right direction before diving into it.

I don't think that there is any interface needed more than what is
already in the compiler.

Paolo