On 9/4/18 9:27 AM, Wilco Dijkstra wrote:
> 
> ping
> 
> 
> 
> 
> From: Wilco Dijkstra
> Sent: 18 June 2018 15:01
> To: GCC Patches
> Cc: nd; Joseph Myers
> Subject: [PATCH v3] Change default to -fno-math-errno
>   
> 
> GCC currently defaults to -fmath-errno.  This generates code assuming math
> functions set errno and the application checks errno.  Few applications
> test errno and various systems and math libraries no longer set errno since it
> is optional.  GCC generates much faster code for simple math functions with
> -fno-math-errno such as sqrt and lround (avoiding a call and PLT redirection).
> Therefore it is reasonable to change the default to -fno-math-errno.  This is
> already the case for non-C languages.  Only change the default for C99 and
> later.
> 
> long f(float x) { return lroundf(x) + 1; }
> 
> by default:
> 
> f:
>         str     x30, [sp, -16]!
>         bl      lroundf
>         add     x0, x0, 1
>         ldr     x30, [sp], 16
>         ret
> 
> With -fno-math-errno:
> 
> f:
>         fcvtas  x0, s0
>         add     x0, x0, 1
>         ret
> 
> Passes regress on AArch64. OK for commit?
> 
> ChangeLog:
> 2018-06-18  Wilco Dijkstra  <wdijk...@arm.com>
> 
>         * common.opt (fmath-errno): Change default to 0.
>         * opts.c (set_fast_math_flags): Force -fno-math-errno with 
> -ffast-math.
>         * c-family/c-opts.c (c_common_init_options_struct): Set 
> flag_errno_math
>         to special value.
>         (c_common_post_options): Set flag_errno_math default based on 
> language.
> 
> doc/
>         * invoke.texi (-fmath-errno) Update documentation.
> 
> testsuite/
> 
>         * gcc.dg/errno-1.c: Add -fmath-errno.
>         * gcc.dg/torture/pr68264.c: Likewise.
>         * gcc.dg/tree-ssa/ssa-dse-15.c: Likewise.
>         * gcc.target/aarch64/no-inline-lrint_1.c: Likewise.
So I went back and reviewed all the discussion around this.  I'm still
having trouble getting comfortable with flipping the default -- unless
we know ahead of time that the target runtime doesn't set errno on any
of the math routines.  That implies a target hook to describe the
runtime's handling off errno in math functions.  It also introduces
target dependencies early in the GIMPLE pipeline which is generally
counter to design goals around GIMPLE.

Essentially if we flip the default, we run the risk that user code which
does check this stuff will silently break.  That's not a good position
to take IMHO.

One could also argue that if we're using -fno-math-errno and we see
errno read after a math call without it being set/clobbered by some
other non-math call then we should be warning the user.  That'd be some
kind of propagation engine in gimple.  That would make flipping the
default more reasonable -- we'd have a reasonable chance of warning the
user that their code is potentially buggy and may need adjustment.

That led me to wonder if we could prove that for the majority of FP
intensive codes that even if the library set errno that nobody could
possibly be reading it, then we could in large part treat those builtin
calls as -fno-math-errno (we'd mark them somehow and check the mark at
GIMPLE->RTL expansion time (and possibly other points) to allow us to
generate machine instructions rather than library calls).  That would
get most of the benefit without the possibility to breaking user code.

I'm willing to go with Joseph's recommendation here, but I'm not really
comfortable acking the patch as-is on my own.

jeff

Reply via email to