This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] PR target/69225: Set FLT_EVAL_METHOD to 2 only if 387 FPU is used
- From: Uros Bizjak <ubizjak at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 12 Jan 2016 13:32:05 +0100
- Subject: Re: [PATCH] PR target/69225: Set FLT_EVAL_METHOD to 2 only if 387 FPU is used
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOp=Tq=mCWWAEi82VGJEp_sbF1e4GYMcjQBpK7LFYeUsJg at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1601120014510 dot 15518 at digraph dot polyomino dot org dot uk> <CAFULd4YYp+zKXDh+p45+H+OG30wyi+=ZOgS2tyLk9tXOyjP0jQ at mail dot gmail dot com> <20160112111850 dot GD3017 at tucnak dot redhat dot com> <CAFULd4ZRmtooD2A+G6iWaSpAQvY8Jt1tS582G7bpj7HpjtUxSA at mail dot gmail dot com>
On Tue, Jan 12, 2016 at 1:12 PM, Uros Bizjak <ubizjak@gmail.com> wrote:
> On Tue, Jan 12, 2016 at 12:18 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>> On Tue, Jan 12, 2016 at 12:10:20PM +0100, Uros Bizjak wrote:
>>> On Tue, Jan 12, 2016 at 1:15 AM, Joseph Myers <joseph@codesourcery.com> wrote:
>>> > On Mon, 11 Jan 2016, H.J. Lu wrote:
>>> >
>>> >> Here is the updated patch. Joseph, is this OK?
>>> >
>>> > I have no objections to this patch.
>>>
>>> Thinking some more, it looks to me that we also have to return 2 when
>>> SSE2 (SSE doubles) is not enabled.
>>>
>>> I'm testing following patch:
>>
>> That looks weird. If TARGET_80387 and !TARGET_SSE_MATH, then no matter
>> whether sse2 is enabled or not, normal floating point operations will be
>> performed in 387 stack and thus FLT_EVAL_METHOD should be 2, not 0.
>> Do you want to do this because some instructions might be vectorized and
>> therefore end up in sse registers? For -std=c99 that shouldn't happen,
>> already the C FE would promote all the arithmetics to be done in long
>> doubles, and for -std=gnu99 it is acceptable if non-vectorized computations
>> honor FLT_EVAL_METHOD and vectorized ones don't.
>
> Eh, today is just not the day for science.
>
> Hopefully, the logic in the patch below is correct:
>
> diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
> index 6c63871..5b42e89 100644
> --- a/gcc/config/i386/i386.h
> +++ b/gcc/config/i386/i386.h
> @@ -693,8 +693,9 @@ extern const char *host_detect_local_cpu (int
> argc, const char **argv);
> only SSE, rounding is correct; when using both SSE and the FPU,
> the rounding precision is indeterminate, since either may be chosen
> apparently at random. */
> -#define TARGET_FLT_EVAL_METHOD \
> - (TARGET_MIX_SSE_I387 ? -1 : (TARGET_80387 && !TARGET_SSE_MATH) ? 2 : 0)
> +#define TARGET_FLT_EVAL_METHOD \
> + (TARGET_MIX_SSE_I387 ? -1 \
> + : TARGET_80387 && !(TARGET_SSE2 && TARGET_SSE_MATH) ? 2 : 0)
>
> /* Whether to allow x87 floating-point arithmetic on MODE (one of
> SFmode, DFmode and XFmode) in the current excess precision
Using this patch, SSE math won't be emitted for a simple testcase
using " -O2 -msse -m32 -std=c99 -mfpmath=sse" compile flags:
float test (float a, float b)
{
return a + b;
}
since we start with:
test (float a, float b)
{
long double _2;
long double _4;
long double _5;
float _6;
<bb 2>:
_2 = (long double) a_1(D);
_4 = (long double) b_3(D);
_5 = _2 + _4;
_6 = (float) _5;
return _6;
}
This is counter-intuitive, so I'd say we leave things as they are. The
situation where only floats are evaluated as floats and doubles are
evaluated as long doubles is not covered in the FLT_EVAL_METHOD spec.
Uros.