RE: MIPS Maintainers
Thanks to all. Matthew > -Original Message- > From: Eric Christopher [mailto:echri...@gmail.com] > Sent: 26 September 2014 21:07 > To: Jeff Law > Cc: Moore, Catherine; Matthew Fortune; GCC > Subject: Re: MIPS Maintainers > > Congratulations guys! > > -eric > > On Fri, Sep 26, 2014 at 1:01 PM, Jeff Law wrote: > > > > Sorry this has taken so long, the delays have been totally mine in not > > following-up to get votes, then tally them from the steering committee. > > > > I'm pleased to announce that Catherine Moore and Matthew Fortune have been > > appointed as maintainers for the MIPS port. > > > > Catherine & Matthew, please update the MAINTAINERS file appropriately. > > > > Thanks for everyone's patience, > > Jeff
Is "optimize" attribute on fndecl handled differently?
I’m trying to get the Fortran front-end to add function-specific optimization
flags to certain functions (those that request IEEE compliance through use of
the specific Fortran module). It seems simple enough, adding the attribute to
the fndecl, but though I’ve tried to do so at two different places (when we
first build the function decl, and when we later call it), both fail with:
Warning: ‘optimize’ attribute directive ignored [-Wattributes]
I’m getting the feeling that maybe it’s because I gave the attribute a string
value, and it’s expecting a tree already… but the functions to do so are not
generic, they’re in c-family, which probably means I can’t use them.
Any idea how I could get to the result I want? (setting options from the
Fortran front-end)
Thanks,
FX
Index: trans-decl.c
===
--- trans-decl.c(revision 215668)
+++ trans-decl.c(working copy)
@@ -1961,6 +1961,13 @@
TREE_USED (fndecl) = 1;
attributes = add_attributes_to_decl (attr, NULL_TREE);
+
+#define OPT "fno-unsafe-math-optimizations"
+ tree opt = build_tree_list (NULL_TREE, build_string (strlen (OPT), OPT));
+ attributes = tree_cons (get_identifier ("optimize"), opt, attributes);
+#undef OPT
+
decl_attributes (&fndecl, attributes, 0);
/* Figure out the return type of the declared function, and build a
@@ -5760,8 +5767,19 @@
the floating point state. */
ieee = is_ieee_module_used (ns);
if (ieee)
-fpstate = save_fp_state (&init);
+{
+ tree attributes;
+ fpstate = save_fp_state (&init);
+
+#define OPT "fno-unsafe-math-optimizations"
+ tree opt = build_tree_list (NULL_TREE, build_string (strlen (OPT), OPT));
+ attributes = tree_cons (get_identifier ("optimize"), opt, NULL_TREE);
+ decl_attributes (&fndecl, attributes, 0);
+#undef OPT
+}
+
/* Now generate the code for the body of this function. */
gfc_init_block (&body);
Re: Is "optimize" attribute on fndecl handled differently?
On Sun, Sep 28, 2014 at 5:24 PM, FX wrote: > I’m trying to get the Fortran front-end to add function-specific optimization > flags to certain functions (those that request IEEE compliance through use of > the specific Fortran module). It seems simple enough, adding the attribute to > the fndecl, but though I’ve tried to do so at two different places (when we > first build the function decl, and when we later call it), both fail with: > > Warning: ‘optimize’ attribute directive ignored [-Wattributes] > > I’m getting the feeling that maybe it’s because I gave the attribute a string > value, and it’s expecting a tree already… but the functions to do so are not > generic, they’re in c-family, which probably means I can’t use them. > > Any idea how I could get to the result I want? (setting options from the > Fortran front-end) AFAIU, it looks like you run into the warning from decl_attributes at "if (spec == NULL)" where spec is the attribute specification. I don't think you want to go through that path (of decl_attributes); instead you probably want to set DECL_FUNCTION_SPECIFIC_OPTIMIZATION directly. You've found handle_optimize_attribute and parse_optimize_options in c-family/c-common.c. . 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. Hope this helps. Thanks for all the work you're putting into this! Ciao! Steven
Re: Autotuning parameters/heuristics within gcc - best place to start?
On 09/26/14 07:47:05, Andi Kleen wrote: > One example of an existing autotuner is the gccflags tuner in opentuner. Although dated, ACOVEA might offer up some ideas. http://stderr.org/doc/acovea/html/acovea_4.html
Re: Is "optimize" attribute on fndecl handled differently?
> 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. 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);
}
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?
FX
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);*/
> 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
Re: Is "optimize" attribute on fndecl handled differently?
tl;dr: there is a bug in optimization options saving/restoring. See after the
break for simple C testcase.
> 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.
It’s not them, but this got me looking into the right place.
In my case, opts.c’s set_fast_math_flags() is called three times:
1. first, from toplev_main -> decode_options -> default_options_optimization
-> handle_generated_option -> handle_option -> common_handle_option
2. then, from toplev_main -> decode_options -> read_cmdline_option ->
handle_option -> common_handle_option
3. then, from my own build_function_decl -> parse_optimize_options ->
decode_options -> default_options_optimization -> handle_generated_option ->
handle_option -> common_handle_option
At 1 and 3, it’s called with value = 0, and at 2, with value = 1. So it is
indeed a bug: because we re-parse the defaults at 3, we reset some of the flags
dependent on -ffast-math (the ones quoted before), overwriting their earlier
value.
PS: There is also something similar with
align_functions/align_jumps/align_loops flags, but I don’t have time to chase
it right now.
This is easy to see with a simple C test case:
//__attribute__ ((optimize("strength-reduce")))
int foo (float x) { return __builtin_isnan(x); }
Compiled with -O3 -ffast-math, the isnan is simplified out (fast math means no
NaNs). If you uncomment the attribute (chosen because it’s actually useless),
and compile again with -O3 -ffast-math: the isnan test is not simplified any
more. This is because the codepath through default_options_optimization() has
overwritten the value of the flags handled in set_fast_math_flags():
flag_finite_math_only, flag_signed_zeros, flag_trapping_math and
flag_unsafe_math_optimizations.
I’m CC’ing the maintainers who added the optimize attribute in the first place,
as they might have an idea how to fix this. This is way beyond my league!
Thanks Steven for your help!
FX
Re: Is "optimize" attribute on fndecl handled differently?
Filed as PR63401: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63401
> This is easy to see with a simple C test case:
>
> //__attribute__ ((optimize("strength-reduce")))
> int foo (float x) { return __builtin_isnan(x); }
>
> Compiled with -O3 -ffast-math, the isnan is simplified out (fast math means
> no NaNs). If you uncomment the attribute (chosen because it’s actually
> useless), and compile again with -O3 -ffast-math: the isnan test is not
> simplified any more. This is because the codepath through
> default_options_optimization() has overwritten the value of the flags handled
> in set_fast_math_flags(): flag_finite_math_only, flag_signed_zeros,
> flag_trapping_math and flag_unsafe_math_optimizations.
>
> I’m CC’ing the maintainers who added the optimize attribute in the first
> place, as they might have an idea how to fix this. This is way beyond my
> league!
>
>
> Thanks Steven for your help!
> FX
gcc-5-20140928 is now available
Snapshot gcc-5-20140928 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20140928/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 215672 You'll find: gcc-5-20140928.tar.bz2 Complete GCC MD5=fa59cf0bda0ec951d42dab55b69bde9b SHA1=76cc638130e29953e45ffb265e585e3aa500e812 Diffs from 5-20140921 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
