Re: [PATCH] ARM half-precision floating point, 8/8 (test cases)

[Sandra Loosemore <sandra at codesourcery dot com>]

Paolo Bonzini wrote:
> Richard Guenther wrote:
> > On Thu, Apr 16, 2009 at 12:29 AM, Sandra Loosemore
> > <sandra@codesourcery.com> wrote:
> > > Last piece of the half-precision puzzle!  Here are a lot of new test cases.
> > I'm missing a testcase that verifies what happens if I declare
> >
> > float x __attribute__((mode(HF)));
> >
> > on a target that doesn't support it.
>
> It's failing for two reasons:
>
> 1) Sandra placed HFmode in config/arm/arm-modes.def (I think this makes
> sense if she keeps the target hooks as they are, otherwise probably not).
>
> 2) The default implementation of scalar_mode_supported_p returns false
> for HFmode.  So it fails even on ARM.
>
> Probably a more sensible default implementation of
> scalar_mode_supported_p would use have_regs_of_mode.  Or maybe
> scalar_mode_supported_p should be ditched totally in favor of
> have_regs_of_mode, but that would require auditing all targets that
> support decimal floating-point and fixed-point arithmetic.

I'm trying to figure out what I need to do here.

It seems clear to me that making scalar_mode_supported_p return true for HFmode 
is wrong, since the hook is documented as: "For a scalar mode to be considered 
supported, all the basic arithmetic and comparisons must work."  This is 
explicitly not the case here.

If we want __attribute__((mode(HF))) to work anyway, I suppose that means adding 
another target hook, and fixing handle_mode_attribute to use it instead of 
scalar_mode_supported_p.

If the current behavior is deemed to be correct, I can add an ARM-specific test 
case to make sure __attribute__((mode(HF))) fails.  But I don't think it's right 
to add a test that it fails on *other* targets, because other targets might come 
along and implement HFmode with semantics such that it does support arithmetic 
and comparisons.

Comments?

-Sandra