On Sun, Dec 11, 2016 at 5:16 PM, Uros Bizjak <ubiz...@gmail.com> wrote:
> On Fri, Dec 9, 2016 at 11:09 AM, Richard Biener
> <richard.guent...@gmail.com> wrote:
>> On Thu, Dec 8, 2016 at 10:44 PM, Uros Bizjak <ubiz...@gmail.com> wrote:
>>> Hello!
>>>
>>> Attached patch fixes fall-out from excess-precision improvements
>>> patch. As shown in the PR, the code throughout the compiler assumes
>>> FLAG_PRECISION_FAST when flag_unsafe_math_optimizations flag is in
>>> effect. The patch puts back two lines, removed by excess-precision
>>> improvements patch.
>>>
>>> 2016-12-08 Uros Bizjak <ubiz...@gmail.com>
>>>
>>> PR middle-end/78738
>>> * toplev.c (init_excess_precision): Initialize flag_excess_precision
>>> to EXCESS_PRECISION_FAST for flag_unsafe_math_optimizations.
>>>
>>> testsuite/ChangeLog:
>>>
>>> 2016-12-08 Uros Bizjak <ubiz...@gmail.com>
>>>
>>> PR middle-end/78738
>>> * gcc.target/i386/pr78738.c: New test.
>>>
>>> Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
>>>
>>> OK for mainline?
>>
>> Hmm, I think it belongs to set_unsafe_math_optimization_flags instead
>> (and be consistent if -fexcess-precision was manually specified).
>>
>> Also where do we assume connection between -funsafe-math-optimizations
>> and FLAG_PRECISION_FAST? We have two flags so we should fix any
>> user that looks at one but means the other.
>
> The failure is caused by the call to ix86_emit_i387_round in
> "lround<X87MODEF:mode><SWI248x:mode>2" expander. This expander is
> enabled for x87 math when flag_unsafe_math_optimizations is enabled.
> In the called ix86_emit_i387_round, DFmode PLUS pattern is manually
> emitted:
>
> emit_insn (gen_rtx_SET (e2, gen_rtx_PLUS (inmode, e1, half)));
>
> but due to the definition of X87_ENABLE_ARITH, DFmode fadd pattern
> remains disabled.
>
> It is possible to fix the failure by enabling X87_ENABLE_ARITH (and
> X87_ENABLE_FLOAT) for flag_unsafe_math_optimizations (as is the case
> in the attached v2 patch), but since gcc-6.x does
>
> if (flag_unsafe_math_optimizations)
> flag_excess_precision = EXCESS_PRECISION_FAST;
>
> I though it was worth mentioning the difference between gcc-6 and
> gcc-7. Probably, x87 is the only target that cares for it, in which
> case the attached patch is sufficient.
I think that patch is the correct correctness fix.
With respect to GCC 6 vs. GCC 7 behavior I believe it would be more
reasonable to set EXCESS_PRECISION_FAST by -ffast-math/-Ofast
rather than from simply -funsafe-math-optimizations (which is an option
directly controlling "legacy" controlled stuff which should be moved
under a more specific option umbrella).
Richard.
> Uros.
>
>
> --cut here--
> Index: i386.h
> ===================================================================
> --- i386.h (revision 243523)
> +++ i386.h (working copy)
> @@ -693,13 +693,16 @@
> /* Whether to allow x87 floating-point arithmetic on MODE (one of
> SFmode, DFmode and XFmode) in the current excess precision
> configuration. */
> -#define X87_ENABLE_ARITH(MODE) \
> - (flag_excess_precision == EXCESS_PRECISION_FAST || (MODE) == XFmode)
> +#define X87_ENABLE_ARITH(MODE) \
> + (flag_unsafe_math_optimizations \
> + || flag_excess_precision == EXCESS_PRECISION_FAST \
> + || (MODE) == XFmode)
>
> /* Likewise, whether to allow direct conversions from integer mode
> IMODE (HImode, SImode or DImode) to MODE. */
> #define X87_ENABLE_FLOAT(MODE, IMODE) \
> - (flag_excess_precision == EXCESS_PRECISION_FAST \
> + (flag_unsafe_math_optimizations \
> + || flag_excess_precision == EXCESS_PRECISION_FAST \
> || (MODE) == XFmode \
> || ((MODE) == DFmode && (IMODE) == SImode) \
> || (IMODE) == HImode)
> --cut here--
