This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Is "optimize" attribute on fndecl handled differently?

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);*/
>     = build_optimization_node (&global_options);
>   debug_tree (optimization_current_node);
>   /* 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)â:
>> 1,3d0
>> <     align_functions (0x10)
>> <     align_jumps (0x10)
>> <     align_loops (0x10)
>> 26d22
>> <     flag_finite_math_only (0x1)
>> 71a68
>> >     flag_signed_zeros (0x1)
>> 78a76
>> >     flag_trapping_math (0x1)
>> 113d110
>> <     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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]