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)”:
>
>> 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.
Ciao!
Steven
