This is the mail archive of the
mailing list for the GCC project.
Re: Is "optimize" attribute on fndecl handled differently?
- From: Steven Bosscher <stevenb dot gcc at gmail dot com>
- To: FX <fxcoudert at gmail dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Sun, 28 Sep 2014 23:05:09 +0200
- Subject: Re: Is "optimize" attribute on fndecl handled differently?
- Authentication-results: sourceware.org; auth=none
- References: <240301BA-258A-417D-832E-24605247BCB2 at gmail dot com> <CABu31nM74GDqUdn1txoG2OeC=HB2JpmQ+pYP9P_oZyr9XC1wCw at mail dot gmail dot com> <B8231714-1383-4397-99E1-45AD11233624 at gmail dot com>
On Sun, Sep 28, 2014 at 10:28 PM, FX wrote:
>> It looks like parse_optimize_options has nothing c-family specific in
>> it, so it could be moved to attribs.c. Then you'd use
>> build_optimization_node to set DECL_FUNCTION_SPECIFIC_OPTIMIZATION, as
>> done in c-common.c:handle_optimize_attribute.
> Yep, Iâve done it that way, it works fine.
> Thereâs one surprise: a few flags (flag_finite_math_only, flag_signed_zeros, flag_trapping_math, flag_unsafe_math_optimizations) seem to appear or disappear when I set specific flags for a function.
I suspect this has something to do with the following set of flags:
options.c: false, /* frontend_set_flag_associative_math */
options.c: false, /* frontend_set_flag_cx_limited_range */
options.c: false, /* frontend_set_flag_finite_math_only */
options.c: false, /* frontend_set_flag_errno_math */
options.c: false, /* frontend_set_flag_reciprocal_math */
options.c: false, /* frontend_set_flag_rounding_math */
options.c: false, /* frontend_set_flag_signaling_nans */
options.c: false, /* frontend_set_flag_signed_zeros */
options.c: false, /* frontend_set_flag_trapping_math */
options.c: false, /* frontend_set_flag_unsafe_math_optimizations */
> What I do is this:
> static void
> add_ieee_options (tree fndecl)
> struct cl_optimization cur_opts;
> /* Save current options. */
> cl_optimization_save (&cur_opts, &global_options);
> /* Parse options, and update the vector. */
> /* parse_optimize_options (opts, true);*/
> DECL_FUNCTION_SPECIFIC_OPTIMIZATION (fndecl)
> = build_optimization_node (&global_options);
> debug_tree (optimization_current_node);
> debug_tree (DECL_FUNCTION_SPECIFIC_OPTIMIZATION (fndecl));
> /* Restore current options. */
> cl_optimization_restore (&global_options, &cur_opts);
Looks perfectly reasonable.
> So, even if I donât change anything to the local options (global is: -O3 -ffast-math), I see some differences between âoptimization_current_nodeâ and "DECL_FUNCTION_SPECIFIC_OPTIMIZATION (fndecl)â:
>> < align_functions (0x10)
>> < align_jumps (0x10)
>> < align_loops (0x10)
>> < flag_finite_math_only (0x1)
>> > flag_signed_zeros (0x1)
>> > flag_trapping_math (0x1)
>> < flag_unsafe_math_optimizations (0x1)
> Is that a bug in optimization handling, or am I missing something?
The saving/restoring of options includes those flags, so the problem
is probably not there.
I suspect that parse_optimize_options doesn't handle those
frontend_set_flag_* options. That would be a bug, IMHO. The fortran
front end sets two of those front-end flags:
fortran/options.c: opts->frontend_set_flag_errno_math = true;
fortran/options.c: opts->frontend_set_flag_associative_math = true;
The effect of these frontend_set_flag_* is that the shared options
handling system (opts.c) defers setting those flags to (surprise) the
front end. Perhaps parse_optimize_options goes through the shared
option handling, and you need to re-setup the frontend_set_flag_*
flags manually somehow. Seems backward, though, but GDB should be able
to help you out (the flags after parse_optimize_options would be
different from the settings in the initial global_options).
Unfortunately I can't find if/where there is some explanation for
these frontend_set_flag_* options -- how they're supposed to work and
who's responsible for setting them.