Re: [google] Add options to pattern match function name for hotness attributes
I've updated the patch using deferred option.
http://codereview.appspot.com/6281047
Thanks,
Dehao
The new patch:
2012-06-01 Dehao Chen
* gcc/cgraph.c (cgraph_match_attribute_by_name): New function.
(cgraph_node): Add attribute to function decl.
* gcc/opts-global.c (add_attribute_list_to_vector): New function.
(handle_common_deferred_options): Handle new options.
* gcc/opts.c (common_handle_option): Handle new options.
* gcc/opts.h (attribute_pair): New type.
* gcc/common.opt (flag_function_attribute_list): New option.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 188050)
+++ gcc/doc/invoke.texi (working copy)
@@ -362,7 +362,8 @@
-fdelete-null-pointer-checks -fdse -fdevirtualize -fdse @gol
-fearly-inlining -fipa-sra -fexpensive-optimizations -ffast-math @gol
-ffinite-math-only -ffloat-store -fexcess-precision=@var{style} @gol
--fforward-propagate -ffp-contract=@var{style} -ffunction-sections @gol
+-fforward-propagate -ffp-contract=@var{style} @gol
+-ffunction-attribute-list -ffunction-sections @gol
-fgcse -fgcse-after-reload -fgcse-las -fgcse-lm -fgraphite-identity @gol
-fgcse-sm -fif-conversion -fif-conversion2 -findirect-inlining @gol
-finline-functions -finline-functions-called-once -finline-limit=@var{n} @gol
@@ -8585,6 +8586,10 @@
specify this option and you may have problems with debugging if
you specify both this option and @option{-g}.
+@item -ffunction-attribute-list
+@opindex ffunction-attribute-list
+List of function name patterns that will be applied specified attribute.
+
@item -fbranch-target-load-optimize
@opindex fbranch-target-load-optimize
Perform branch target register load optimization before prologue / epilogue
Index: gcc/cgraph.c
===
--- gcc/cgraph.c(revision 188050)
+++ gcc/cgraph.c(working copy)
@@ -99,6 +99,7 @@
#include "ipa-utils.h"
#include "lto-streamer.h"
#include "l-ipo.h"
+#include "opts.h"
const char * const ld_plugin_symbol_resolution_names[]=
{
@@ -520,6 +521,32 @@
}
}
+/* Match FNDECL's name with user specified patterns. If match is found, add
+ attributes to FNDECL.
+ name matches with pattern, iff one of the following conditions satisfy:
+ 1. strcmp (name, pattern) != 0
+ 2. pattern[len - 1] = '*' && strncmp (name, pattern, len - 1) != 0 */
+static void
+cgraph_match_attribute_by_name (tree fndecl)
+{
+ unsigned i;
+ attribute_pair_p p;
+ const char *name = lang_hooks.decl_printable_name(fndecl, 0);
+
+ if (!name)
+return;
+
+ FOR_EACH_VEC_ELT (attribute_pair_p, function_attribute_list, i, p)
+{
+ char *n = p->name;
+ int len = strlen (n);
+ if ((n[len - 1] == '*' && !strncmp (name, n, len - 1))
+ || !strcmp (name, n))
+decl_attributes (&fndecl, tree_cons (
+get_identifier (p->attribute), NULL, NULL), 0);
+}
+}
+
/* Return cgraph node assigned to DECL. Create new one when needed. */
struct cgraph_node *
@@ -554,6 +581,7 @@
node->origin->nested = node;
}
cgraph_add_assembler_hash_node (node);
+ cgraph_match_attribute_by_name (decl);
return node;
}
Index: gcc/opts.c
===
--- gcc/opts.c (revision 188050)
+++ gcc/opts.c (working copy)
@@ -1647,6 +1647,10 @@
/* Deferred. */
break;
+case OPT_ffunction_attribute_list_:
+ /* Deferred. */
+ break;
+
case OPT_fsched_verbose_:
#ifdef INSN_SCHEDULING
/* Handled with Var in common.opt. */
Index: gcc/opts.h
===
--- gcc/opts.h (revision 188050)
+++ gcc/opts.h (working copy)
@@ -272,6 +272,15 @@
struct cl_option_handler_func handlers[3];
};
+typedef struct {
+ char *name;
+ char *attribute;
+} attribute_pair;
+typedef attribute_pair *attribute_pair_p;
+DEF_VEC_P(attribute_pair_p);
+DEF_VEC_ALLOC_P(attribute_pair_p,heap);
+extern VEC(attribute_pair_p,heap) *function_attribute_list;
+
/* Input file names. */
extern const char **in_fnames;
Index: gcc/common.opt
===
--- gcc/common.opt (revision 188050)
+++ gcc/common.opt (working copy)
@@ -1242,6 +1242,10 @@
Common Report Var(flag_function_sections)
Place each function into its own section
+ffunction-attribute-list=
+Common Joined RejectNegative Var(common_deferred_options) Defer
+-ffunction-attribute-list=attribute:name,... Add attribute to named functions
+
fgcda=
Common Joined RejectNegative Var(gcov_da_name)
Set the gcov data file name.
Index: gcc/opts-global.c
===
--- gcc/opts-global.c (revision 188050)
+++ gcc/opts-global.c (working copy)
@@ -50,6 +50,8 @@
const char **in_fnames;
unsigned num_in_fnames;
+V
libgo patch committed: Better SWIG interface for allocating memory
This patch to libgo makes a better interface available to SWIG when
C/C++ code wants to allocate memory that is garbage collected by Go.
Previously if the only pointer to the memory were held in the C/C++
code, it was possible for the garbage collector to discard the memory
before the C/C++ function returned. This patch fixes this in a
straightforward way: it keeps a list of allocated memory, and drops the
list when returning to Go. Bootstrapped and ran Go testsuite, and also
SWIG testsuite, on x86_64-unknown-linux-gnu. Committed to mainline and
4.7 branch.
Ian
diff -r 9b3e0b116fe4 libgo/go/syscall/libcall_support.go
--- a/libgo/go/syscall/libcall_support.go Wed May 30 16:04:09 2012 -0700
+++ b/libgo/go/syscall/libcall_support.go Sun Jun 03 22:30:03 2012 -0700
@@ -10,3 +10,9 @@
func Exitsyscall()
func GetErrno() Errno
func SetErrno(Errno)
+
+// These functions are used by CGO and SWIG.
+func Cgocall()
+func CgocallDone()
+func CgocallBack()
+func CgocallBackDone()
diff -r 9b3e0b116fe4 libgo/runtime/go-cgo.c
--- a/libgo/runtime/go-cgo.c Wed May 30 16:04:09 2012 -0700
+++ b/libgo/runtime/go-cgo.c Sun Jun 03 22:30:03 2012 -0700
@@ -4,11 +4,116 @@
Use of this source code is governed by a BSD-style
license that can be found in the LICENSE file. */
+#include "runtime.h"
#include "go-alloc.h"
#include "interface.h"
#include "go-panic.h"
#include "go-string.h"
+/* Go memory allocated by code not written in Go. We keep a linked
+ list of these allocations so that the garbage collector can see
+ them. */
+
+struct cgoalloc
+{
+ struct cgoalloc *next;
+ void *alloc;
+};
+
+/* Prepare to call from code written in Go to code written in C or
+ C++. This takes the current goroutine out of the Go scheduler, as
+ though it were making a system call. Otherwise the program can
+ lock up if the C code goes to sleep on a mutex or for some other
+ reason. This idea is to call this function, then immediately call
+ the C/C++ function. After the C/C++ function returns, call
+ syscall_cgocalldone. The usual Go code would look like
+
+ syscall.Cgocall()
+ defer syscall.Cgocalldone()
+ cfunction()
+
+ */
+
+/* We let Go code call these via the syscall package. */
+void syscall_cgocall(void) __asm__ ("syscall.Cgocall");
+void syscall_cgocalldone(void) __asm__ ("syscall.CgocallDone");
+void syscall_cgocallback(void) __asm__ ("syscall.CgocallBack");
+void syscall_cgocallbackdone(void) __asm__ ("syscall.CgocallBackDone");
+
+void
+syscall_cgocall ()
+{
+ M* m;
+ G* g;
+
+ m = runtime_m ();
+ ++m->ncgocall;
+ g = runtime_g ();
+ ++g->ncgo;
+ runtime_entersyscall ();
+}
+
+/* Prepare to return to Go code from C/C++ code. */
+
+void
+syscall_cgocalldone ()
+{
+ G* g;
+
+ g = runtime_g ();
+ __go_assert (g != NULL);
+ --g->ncgo;
+ if (g->ncgo == 0)
+{
+ /* We are going back to Go, and we are not in a recursive call.
+ Let the garbage collector clean up any unreferenced
+ memory. */
+ g->cgoalloc = NULL;
+}
+
+ /* If we are invoked because the C function called _cgo_panic, then
+ _cgo_panic will already have exited syscall mode. */
+ if (g->status == Gsyscall)
+runtime_exitsyscall ();
+}
+
+/* Call back from C/C++ code to Go code. */
+
+void
+syscall_cgocallback ()
+{
+ runtime_exitsyscall ();
+}
+
+/* Prepare to return to C/C++ code from a callback to Go code. */
+
+void
+syscall_cgocallbackdone ()
+{
+ runtime_entersyscall ();
+}
+
+/* Allocate memory and save it in a list visible to the Go garbage
+ collector. */
+
+void *
+alloc_saved (size_t n)
+{
+ void *ret;
+ G *g;
+ struct cgoalloc *c;
+
+ ret = __go_alloc (n);
+
+ g = runtime_g ();
+ c = (struct cgoalloc *) __go_alloc (sizeof (struct cgoalloc));
+ c->next = g->cgoalloc;
+ c->alloc = ret;
+ g->cgoalloc = c;
+
+ return ret;
+}
+
/* These are routines used by SWIG. The gc runtime library provides
the same routines under the same name, though in that case the code
is required to import runtime/cgo. */
@@ -16,7 +121,12 @@
void *
_cgo_allocate (size_t n)
{
- return __go_alloc (n);
+ void *ret;
+
+ runtime_exitsyscall ();
+ ret = alloc_saved (n);
+ runtime_entersyscall ();
+ return ret;
}
extern const struct __go_type_descriptor string_type_descriptor
@@ -30,13 +140,39 @@
struct __go_string *ps;
struct __go_empty_interface e;
+ runtime_exitsyscall ();
len = __builtin_strlen (p);
- data = __go_alloc (len);
+ data = alloc_saved (len);
__builtin_memcpy (data, p, len);
- ps = __go_alloc (sizeof *ps);
+ ps = alloc_saved (sizeof *ps);
ps->__data = data;
ps->__length = len;
e.__type_descriptor = &string_type_descriptor;
e.__object = ps;
+
+ /* We don't call runtime_entersyscall here, because normally what
+ will happen is that we will walk up the stack to a Go deferred
+ function that calls recover. However, this will do the wrong
+ thing if this panic is recovered and the stack unwinding is
+
[line-map] simple oneliner that speeds up track-macro-expansion
Hello list, the attached simple patch is a small part of the fix in Bug #53525, but it is independant and offers a noticeable performance improvement for track-macro-expansion. No regressions tested on x86, besides memory usage going up some KB. I don't get why the max_column_hint was zeroed in every macro. Maybe there are pathological cases that I don't see? 2012-06-04 Dimitrios Apostolou * line-map.c (linemap_enter_macro): Don't zero max_column_hint in every macro. This improves performance by reducing the number of reallocations when track-macro-expansion is on. Thanks Dimitris === modified file 'libcpp/line-map.c' --- libcpp/line-map.c 2012-04-30 11:42:12 + +++ libcpp/line-map.c 2012-05-27 06:52:08 + @@ -331,7 +331,6 @@ linemap_enter_macro (struct line_maps *s num_tokens * sizeof (source_location)); LINEMAPS_MACRO_CACHE (set) = LINEMAPS_MACRO_USED (set) - 1; - set->max_column_hint = 0; return map; }
Re: [google] Add options to pattern match function name for hotness attributes
On Mon, Jun 4, 2012 at 9:34 AM, Andi Kleen wrote: > Dehao Chen writes: > >> Hi, >> >> This patch adds 4 flags to enable user to type in a list of name >> patterns. Compiler will match the function name with the given >> patterns, and add "hot", "cold", "likely_hot", "likely_cold" >> attributes to function declaration. The static branch prediction >> checks if a basic block contains call to a annotated function, and set >> the branch probability accordingly. > > I like the idea (and would have some uses for it), but I don't like the > command line options. That will lead to longer and longer command > lines. Could this be made a pragma instead? > > You could still specify it from the Makefile by using -include Thanks for the suggestions. How about we add an option (-ffunction-attribute-list=), and we can also specify this option using "#pragma GCC optimize" in a separate -include file? Thanks, Dehao > > -Andi > > -- > a...@linux.intel.com -- Speaking for myself only
[PATCH] Fix bug added to sparc 64-bit sub_ddmmss() implementation.
Testing in glibc found a bug in one of my longlong.h sparc changes,
fixed thusly and committed to master.
libgcc/
* longlong.h [SPARC] (sub_ddmmss): Fix thinko in previous 64-bit
change.
---
libgcc/ChangeLog |5 +
libgcc/longlong.h |2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/libgcc/ChangeLog b/libgcc/ChangeLog
index 9b4491c..bad8ec0 100644
--- a/libgcc/ChangeLog
+++ b/libgcc/ChangeLog
@@ -1,3 +1,8 @@
+2012-06-03 David S. Miller
+
+ * longlong.h [SPARC] (sub_ddmmss): Fix thinko in previous 64-bit
+ change.
+
2012-05-31 David S. Miller
* longlong.h [SPARC] (umul_ppmm, udiv_qrnnd): Use hardware integer
diff --git a/libgcc/longlong.h b/libgcc/longlong.h
index ad42907..0427718 100644
--- a/libgcc/longlong.h
+++ b/libgcc/longlong.h
@@ -1343,7 +1343,7 @@ UDItype __umulsidi3 (USItype, USItype);
__asm__ ("subcc\t%r5,%6,%1\n\t"\
"sub\t%r3,%4,%0\n\t" \
"movcs\t%%xcc, 1, %2\n\t" \
-"add\t%0, %2, %0" \
+"sub\t%0, %2, %0" \
: "=r" ((UDItype)(sh)),\
"=&r" ((UDItype)(sl)), \
"+r" (__carry) \
--
1.7.10
Re: [google] Add options to pattern match function name for hotness attributes
Dehao Chen writes: > Hi, > > This patch adds 4 flags to enable user to type in a list of name > patterns. Compiler will match the function name with the given > patterns, and add "hot", "cold", "likely_hot", "likely_cold" > attributes to function declaration. The static branch prediction > checks if a basic block contains call to a annotated function, and set > the branch probability accordingly. I like the idea (and would have some uses for it), but I don't like the command line options. That will lead to longer and longer command lines. Could this be made a pragma instead? You could still specify it from the Makefile by using -include -Andi -- a...@linux.intel.com -- Speaking for myself only
Re: [PATCH 2/2] Better system header location detection for built-in macro tokens
On 06/03/2012 06:04 PM, Paolo Carlini wrote: if I apply to below, thus passing an actual loc to build_min_non_dep_loc, there is a diagnostic regression for the locations of libstdc++-v3/testsuite/20_util/bind_ref_neg.cc. If you see something obviously wrong somewhere, just let me know... Nope, it looks fine to me. I guess the change is due to having an explicit location on a tree that used to have none. Jason
Re: [PATCH 2/2] Better system header location detection for built-in macro tokens
On 06/03/2012 05:27 AM, Jason Merrill wrote:
On 06/02/2012 12:40 PM, Paolo Carlini wrote:
That said, the tricks we are playing with the global input_location
vs the loc we are passing around still confuse me quite a lot.
Actually any *assignment* to input_location makes me a bit more
nervous than I was already ;) Do you have any idea whether just
passing down to build_x_modify_expr a different value for loc instead
of assigning to input_location would also work for you? Maybe
together with more throughly forwarding the loc from
build_x_modify_expr itself to the build_min* functions (ie the
project I mentioned above)??
We already pass to build_x_modify_expr the location that he is
assigning to input_location. I would guess that the issue in this
case is with the "in_system_header" macro, which uses input_location.
I think the input_location hack here is OK until we improve our use of
explicit locations to make it unnecessary.
Good.
In any case, as far as I can see, the assignment Dodji is adding just
before calling build_x_modify_expr doesn't change anything for "my"
issue, which actually has to do with build_x_binary_op: if I apply to
below, thus passing an actual loc to build_min_non_dep_loc, there is a
diagnostic regression for the locations of
libstdc++-v3/testsuite/20_util/bind_ref_neg.cc. If you see something
obviously wrong somewhere, just let me know...
Paolo.
///
Index: typeck.c
===
--- typeck.c(revision 188155)
+++ typeck.c(working copy)
@@ -2696,9 +2696,8 @@ finish_class_member_access_expr (tree object, tree
BASELINK_QUALIFIED_P (member) = 1;
orig_name = member;
}
- return build_min_non_dep (COMPONENT_REF, expr,
- orig_object, orig_name,
- NULL_TREE);
+ return build_min_non_dep_loc (UNKNOWN_LOCATION, COMPONENT_REF, expr,
+ orig_object, orig_name, NULL_TREE);
}
return expr;
@@ -2763,7 +2762,7 @@ build_x_indirect_ref (location_t loc, tree expr, r
rval = cp_build_indirect_ref (expr, errorstring, complain);
if (processing_template_decl && rval != error_mark_node)
-return build_min_non_dep (INDIRECT_REF, rval, orig_expr);
+return build_min_non_dep_loc (loc, INDIRECT_REF, rval, orig_expr);
else
return rval;
}
@@ -3631,7 +3630,7 @@ build_x_binary_op (location_t loc, enum tree_code
warn_about_parentheses (code, arg1_code, orig_arg1, arg2_code, orig_arg2);
if (processing_template_decl && expr != error_mark_node)
-return build_min_non_dep (code, expr, orig_arg1, orig_arg2);
+return build_min_non_dep_loc (loc, code, expr, orig_arg1, orig_arg2);
return expr;
}
@@ -3660,8 +3659,8 @@ build_x_array_ref (location_t loc, tree arg1, tree
NULL_TREE, /*overload=*/NULL, complain);
if (processing_template_decl && expr != error_mark_node)
-return build_min_non_dep (ARRAY_REF, expr, orig_arg1, orig_arg2,
- NULL_TREE, NULL_TREE);
+return build_min_non_dep_loc (loc, ARRAY_REF, expr, orig_arg1, orig_arg2,
+ NULL_TREE, NULL_TREE);
return expr;
}
@@ -4764,7 +4763,7 @@ build_x_unary_op (location_t loc, enum tree_code c
}
if (processing_template_decl && exp != error_mark_node)
-exp = build_min_non_dep (code, exp, orig_expr,
+exp = build_min_non_dep_loc (loc, code, exp, orig_expr,
/*For {PRE,POST}{INC,DEC}REMENT_EXPR*/NULL_TREE);
if (TREE_CODE (exp) == ADDR_EXPR)
PTRMEM_OK_P (exp) = ptrmem;
@@ -5624,8 +5623,8 @@ build_x_conditional_expr (location_t loc, tree ife
expr = build_conditional_expr (ifexp, op1, op2, complain);
if (processing_template_decl && expr != error_mark_node)
{
- tree min = build_min_non_dep (COND_EXPR, expr,
- orig_ifexp, orig_op1, orig_op2);
+ tree min = build_min_non_dep_loc (loc, COND_EXPR, expr,
+ orig_ifexp, orig_op1, orig_op2);
/* In C++11, remember that the result is an lvalue or xvalue.
In C++98, lvalue_kind can just assume lvalue in a template. */
if (cxx_dialect >= cxx0x
@@ -5742,7 +5741,8 @@ build_x_compound_expr (location_t loc, tree op1, t
result = cp_build_compound_expr (op1, op2, complain);
if (processing_template_decl && result != error_mark_node)
-return build_min_non_dep (COMPOUND_EXPR, result, orig_op1, orig_op2);
+return build_min_non_dep_loc (loc, COMPOUND_EXPR, result,
+ orig_op1, orig_op2);
return result;
}
Index: tree.c
===
--- tree.c (revision 188155)
+++ tree.c (working copy)
@@ -2086,7 +2086,7 @@ build_min (enum tree_code code, tree tt, ...)
built. */
tree
-build_min_non_d
Re: [gcov] a few improvements
On Sun, Jun 3, 2012 at 10:24 AM, Nathan Sidwell wrote: > On 06/03/12 17:16, Xinliang David Li wrote: > >> Basically it makes it very difficult to rebuild the file with the >> profile data --- which makes problem triaging impossible. What is > > > Can you explain this more -- what exactly are trying to do? Are you trying > to rebuild multiple times with the same coverage data, yes -- for instance, in the context of debugging a compiler problem, you will need to compile the same file multiple times with the same coverage data. David > or something > different?
Re: [gcov] a few improvements
On 06/03/12 17:16, Xinliang David Li wrote: Basically it makes it very difficult to rebuild the file with the profile data --- which makes problem triaging impossible. What is Can you explain this more -- what exactly are trying to do? Are you trying to rebuild multiple times with the same coverage data, or something different?
Re: [C++ Patch] for c++/51214
On Sun, Jun 3, 2012 at 10:56 AM, Fabien Chêne wrote: > 2012/6/3 Jason Merrill : >> On 05/24/2012 09:18 AM, Jason Merrill wrote: >>> >>> OK, thanks. >> >> >> I notice you haven't checked the patch in yet, is there a problem? > > Not at all, just lack of time, so many problems/holidays to tackle at > the moment... That is May month in France ;-) It must be distressing to make up for those 35 hours ;-p -- Gaby
[PATCH] Option to build bare-metal ARM cross-compiler for arm-none-eabi target without libunwind
This is an update to Fredrik Hederstierna's mail and patch from
12 Apr 2012. I think he missed one place where -fexceptions needs
to be changed to -fno-exceptions.
With the attached patch, two of us (a friend and I, one on Linux and
one on Mac) can build Rockbox with gcc-4.7.0. I'll admit I haven't
checked the repository for changes in this area, this patch is based
on stock released gcc-4.7.0.
I have no opinion on Sebastian Huber's idea of making functionality
of this kind implicit with target.
- Larry
diff -ur libgcc-orig/configure libgcc-baremetal/configure
--- libgcc-orig/configure 2012-01-22 22:25:28.0 -0800
+++ libgcc-baremetal/configure 2012-05-31 07:30:36.0 -0700
@@ -600,6 +600,7 @@
set_use_emutls
set_have_cc_tls
vis_hide
+enable_libunwind_exceptions
fixed_point
enable_decimal_float
decimal_float
@@ -697,6 +698,7 @@
with_build_libsubdir
enable_decimal_float
with_system_libunwind
+enable_libunwind_exceptions
enable_sjlj_exceptions
enable_tls
'
@@ -1332,6 +1334,8 @@
enable decimal float extension to C. Selecting 'bid'
or 'dpd' choses which decimal floating point format
to use
+ --disable-libunwind-exceptions
+ disable use of libunwind when build libgcc
--enable-sjlj-exceptions
force use of builtin_setjmp for exceptions
--enable-tlsUse thread-local storage [default=yes]
@@ -4493,6 +4497,15 @@
fi
+# For bare metal toolchain libundwind exceptions can be disabled
+# Check whether --enable-libunwind-exceptions was given.
+if test "${enable_libunwind_exceptions+set}" = set; then :
+ enableval=$enable_libunwind_exceptions; enable_libunwind_exceptions=$enableval
+else
+ enable_libunwind_exceptions=yes
+fi
+
+
# The sjlj test is almost duplicated here and in libgo/configure.ac (for C),
# libstdc++-v3/acinclude.m4 and libjava/configure.ac (for C++), and
# libobjc/configure.ac (for Objective-C).
diff -ur libgcc-orig/configure.ac libgcc-baremetal/configure.ac
--- libgcc-orig/configure.ac 2011-11-07 08:34:31.0 -0800
+++ libgcc-baremetal/configure.ac 2012-05-27 11:49:22.0 -0700
@@ -184,6 +184,14 @@
# config.gcc also contains tests of with_system_libunwind.
GCC_CHECK_UNWIND_GETIPINFO
+# For bare metal toolchain libundwind exceptions can be disabled
+AC_ARG_ENABLE(libunwind-exceptions,
+ [AC_HELP_STRING([--disable-libunwind-exceptions],
+[disable use of libunwind when build libgcc])],
+ [enable_libunwind_exceptions=$enableval],
+ [enable_libunwind_exceptions=yes])
+AC_SUBST(enable_libunwind_exceptions)
+
# The sjlj test is almost duplicated here and in libgo/configure.ac (for C),
# libstdc++-v3/acinclude.m4 and libjava/configure.ac (for C++), and
# libobjc/configure.ac (for Objective-C).
diff -ur libgcc-orig/Makefile.in libgcc-baremetal/Makefile.in
--- libgcc-orig/Makefile.in 2011-11-21 19:01:02.0 -0800
+++ libgcc-baremetal/Makefile.in 2012-05-29 18:45:03.0 -0700
@@ -41,6 +41,7 @@
decimal_float = @decimal_float@
enable_decimal_float = @enable_decimal_float@
fixed_point = @fixed_point@
+enable_libunwind_exceptions = @enable_libunwind_exceptions@
host_noncanonical = @host_noncanonical@
target_noncanonical = @target_noncanonical@
@@ -497,17 +498,23 @@
endif
# Build LIB2_DIVMOD_FUNCS.
+ifeq ($(enable_libunwind_exceptions),yes)
+LIB2_DIVMOD_CFLAGS := -fexceptions -fnon-call-exceptions
+else
+LIB2_DIVMOD_CFLAGS := -fno-exceptions -fno-non-call-exceptions
+endif
+
lib2-divmod-o = $(patsubst %,%$(objext),$(LIB2_DIVMOD_FUNCS))
$(lib2-divmod-o): %$(objext): $(srcdir)/libgcc2.c
$(gcc_compile) -DL$* -c $< \
- -fexceptions -fnon-call-exceptions $(vis_hide)
+ $(LIB2_DIVMOD_CFLAGS) $(vis_hide)
libgcc-objects += $(lib2-divmod-o)
ifeq ($(enable_shared),yes)
lib2-divmod-s-o = $(patsubst %,%_s$(objext),$(LIB2_DIVMOD_FUNCS))
$(lib2-divmod-s-o): %_s$(objext): $(srcdir)/libgcc2.c
$(gcc_s_compile) -DL$* -c $< \
- -fexceptions -fnon-call-exceptions
+ $(LIB2_DIVMOD_CFLAGS) $(vis_hide)
libgcc-s-objects += $(lib2-divmod-s-o)
endif
@@ -810,7 +817,11 @@
# libgcc_eh.a, only LIB2ADDEH matters. If we do, only LIB2ADDEHSTATIC and
# LIB2ADDEHSHARED matter. (Usually all three are identical.)
+ifeq ($(enable_libunwind_exceptions),yes)
c_flags := -fexceptions
+else
+c_flags := -fno-exceptions
+endif
ifeq ($(enable_shared),yes)
Re: [gcov] a few improvements
On Sun, Jun 3, 2012 at 6:10 AM, Nathan Sidwell wrote: > On 06/03/12 05:51, Xinliang David Li wrote: >> >> On Fri, Dec 30, 2011 at 10:25 AM, Nathan Sidwell wrote: >>> >>> I've committed this patch to fix and improve coverage reporting: >>> >>> 1) the time stamp local_tick will be -1 if the user overrides the random >>> seed. In such cases the gcov data file should be deleted, just as it >>> would >>> if the time cannot be determined. >> >> >> The end result is that after a the profile data is used in the >> compilation (with option -fprofile-use -frandom-seed=), it is then >> deleted. Is this intended? This basically makes FDO very hard to use >> when -frandom-seed is used. > > > IIUC the file is deleted after being used. What is the problem you are > encountering? (if you are having a problem, that suggests others on systems > without local_tick are also having problems) Basically it makes it very difficult to rebuild the file with the profile data --- which makes problem triaging impossible. What is worse is that when profile data is missing, gcc silently takes it which gives you no clue you chasing in a completely different path .. David > > nathan
Re: [google] Add options to pattern match function name for hotness attributes
Where is the patch -- the code review link is missing (in the original post). David On Sun, Jun 3, 2012 at 6:14 AM, Dehao Chen wrote: > Thank you guys for the comments, I'll update the patch to : > > 1. generalize the flag to enable other annotations such always_inline. > 2. change to use deferred option. > > Thanks, > Dehao > > On Sun, Jun 3, 2012 at 12:40 PM, Xinliang David Li wrote: >> On Sat, Jun 2, 2012 at 11:11 AM, Jan Hubicka wrote: Actually Dehao also plans to teach the static predictor to understand standard library functions more (e.g IO functions) and add more naming >>> >>> How this differ from annotating the library? >> >> I find them more suitable to be compiler heuristic than being >> function's attribute -- attribute is a much stronger assertion. >> >>> >>> There are indeed quite some possibilities to do about library calls >>> >>> One thing I always wondered about is how to tell predictor that paths >>> containing >>> heavy IO functions don't need to be really opimized to death, since their >>> execution >>> time is dominated by the IO... >>> >> >> Yes -- if branch predictor does the right thing and if function >> splitter is powerful enough, the IO code can be outlined and optimized >> for size :) >> >> based heuristics such as 'error, success, failure, fatal etc). >>> >>> yeah, this is also mentioned by some branch prediction papers. It is bit >>> kludgy >>> in nature (i.e. it won't understand programs written in Czech language) but >>> it >>> is an heuristics after all. >>> >> >> right. >> >> thanks, >> >> David >> >>> Honza thanks, David > Honza >> >> thanks, >> >> David >> > Honza
Re: [C++ Patch] for c++/51214
2012/6/3 Jason Merrill : > On 05/24/2012 09:18 AM, Jason Merrill wrote: >> >> OK, thanks. > > > I notice you haven't checked the patch in yet, is there a problem? Not at all, just lack of time, so many problems/holidays to tackle at the moment... That is May month in France ;-) I'll be checking in it the next few days. -- Fabien
[wwwdocs] Buildstat update for 4.6
Latest results for 4.6.x -tgc Testresults for 4.6.3: i386-pc-solaris2.8 i386-pc-solaris2.10 x86_64-unknown-linux-gnu Index: buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.6/buildstat.html,v retrieving revision 1.11 diff -u -r1.11 buildstat.html --- buildstat.html 4 Apr 2012 20:01:33 - 1.11 +++ buildstat.html 3 Jun 2012 14:58:28 - @@ -108,6 +108,7 @@ i386-pc-solaris2.8 Test results: +http://gcc.gnu.org/ml/gcc-testresults/2012-04/msg02817.html";>4.6.3, http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02401.html";>4.6.3, http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02155.html";>4.6.3, http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01757.html";>4.6.3, @@ -136,6 +137,7 @@ i386-pc-solaris2.10 Test results: +http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg00087.html";>4.6.3, http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01817.html";>4.6.3, http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg02468.html";>4.6.2, http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg00327.html";>4.6.1, @@ -368,6 +370,7 @@ x86_64-unknown-linux-gnu Test results: +http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg02020.html";>4.6.3, http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01688.html";>4.6.3, http://gcc.gnu.org/ml/gcc-testresults/2011-12/msg00968.html";>4.6.2, http://gcc.gnu.org/ml/gcc-testresults/2011-06/msg03135.html";>4.6.1,
RE: [Patch,AVR]: Fix PR46261
> -Original Message- > From: Georg-Johann Lay [mailto:a...@gjlay.de] > Sent: Thursday, May 31, 2012 8:56 AM > To: gcc-patches@gcc.gnu.org > Cc: Denis Chertykov; Weddington, Eric; Richard Henderson > Subject: [Patch,AVR]: Fix PR46261 > > This fixes ICE on any source compiled with -mint8. > Missing definition of UINT16_TYPE (defined to 0) crashed > the compiler when it tries to build wchar stuff. > > As mentioned in the PR, I chose to add the stdint stuff > as a new file. > > The -mint8 part is only lightly tested because there is no > test suite for the non-C compliant code it generates. > > Without -mint8 avr-stdint.h mimics as many as possible definitions > from newlib-stdint.h but for 2 cases where it deviates: > > - SIG_ATOMIC_TYPE is 8-bit, AVR cannot access 16 bits atomically > > - [U]INT_FAST8_TYPE is 8-bit because AVR is an 8-bit machine > > Ok to install? > Ok. Please commit. If it tests with no regressions, you can backport to 4.7 (as mentioned off-list). Eric Weddington
[wwwdocs] Buildstat update for 4.7
Latest results for 4.7.x -tgc Testresults for 4.7.0: hppa64-hp-hpux11.11 i386-pc-solaris2.8 x86_64-apple-darwin11.3.0 Index: buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/buildstat.html,v retrieving revision 1.4 diff -u -r1.4 buildstat.html --- buildstat.html 4 Apr 2012 20:08:45 - 1.4 +++ buildstat.html 3 Jun 2012 14:54:32 - @@ -39,6 +39,14 @@ +hppa64-hp-hpux11.11 + +Test results: +http://gcc.gnu.org/ml/gcc-testresults/2012-04/msg00408.html";>4.7.0 + + + + i386-apple-darwin10.8.0 Test results: @@ -50,6 +58,7 @@ i386-pc-solaris2.8 Test results: +http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg00527.html";>4.7.0, http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02998.html";>4.7.0, http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02619.html";>4.7.0 @@ -124,6 +133,7 @@ x86_64-apple-darwin11.3.0 Test results: +http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg02122.html";>4.7.0, http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02630.html";>4.7.0
Re: [Fortran, patch] PR 48831 - Constant expression (PARAMETER array element) rejected as nonconstant
Thank you Tobias, I thought that "Change name in gfc_check_init_expr" was sufficient. 2012/6/3 Tobias Burnus : > Hi Alessandro, hi all, > > > Alessandro Fanfarillo wrote: >> >> in attachment the patch which includes the review comments provided by >> Tobias. > > > Thanks for the patch, which I committed as Rev. 188152. Congratulation to > your second committed patch. > > Nit: You forgot twice to add the prefix "gfc_" in the ChangeLog; I corrected > it before committal. > > * * * > > If possible, use "-p" when you do a diff. With svn, simply pass "-x -p" (or > --diff-cmd=diff -x '-p -u'); git does this already by default. [Some prefer > "-c" to "-u", which is also fine.] Without the "-p" flag, the result is: > > --- gcc/fortran/check.c (revisione 188147) > +++ gcc/fortran/check.c > @@ -163,7 +163,7 @@ > if (scalar_check (k, n) == FAILURE) > > > While with "-p" flag, one gets: > > --- gcc/fortran/check.c (Revision 188123) > +++ gcc/fortran/check.c > @@ -163,7 +163,7 @@ kind_check (gfc_expr *k, int n, bt type) > if (scalar_check (k, n) == FAILURE) > > > The difference is that the @@ line shows the function name (here: > "kind_check"). That information makes it easier to review a patch as one > then knows more about the context. > > Tobias
Re: [Fortran, patch] PR 48831 - Constant expression (PARAMETER array element) rejected as nonconstant
Hi Alessandro, hi all, Alessandro Fanfarillo wrote: in attachment the patch which includes the review comments provided by Tobias. Thanks for the patch, which I committed as Rev. 188152. Congratulation to your second committed patch. Nit: You forgot twice to add the prefix "gfc_" in the ChangeLog; I corrected it before committal. * * * If possible, use "-p" when you do a diff. With svn, simply pass "-x -p" (or --diff-cmd=diff -x '-p -u'); git does this already by default. [Some prefer "-c" to "-u", which is also fine.] Without the "-p" flag, the result is: --- gcc/fortran/check.c (revisione 188147) +++ gcc/fortran/check.c @@ -163,7 +163,7 @@ if (scalar_check (k, n) == FAILURE) While with "-p" flag, one gets: --- gcc/fortran/check.c(Revision 188123) +++ gcc/fortran/check.c @@ -163,7 +163,7 @@ kind_check (gfc_expr *k, int n, bt type) if (scalar_check (k, n) == FAILURE) The difference is that the @@ line shows the function name (here: "kind_check"). That information makes it easier to review a patch as one then knows more about the context. Tobias
[committed] Reduce maximum PCREL17F branch offsets for PIC code
Sometimes when generating PIC code, a call would exceed its maximum
branch offset and link would fail. This occurs because PIC stubs are
larger than non PIC stubs. Most recently this occurred building the
Debian kde4libs package.
This change adjusts the maximum branch offsets for PIC code so that
the maximum call density is the same as non PIC code.
Tested on hppa-unknown-linux-gnu, hppa2.0w-hp-hpux11.11 and
hppa64-hp-hpux11.11.
Committed to trunk.
Dave
--
J. David Anglin dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
2012-06-03 John David Anglin
* config/pa/pa.h (MAX_PCREL17F_OFFSET): Define.
* config/pa/pa.c (pa_attr_length_millicode_call): Use
MAX_PCREL17F_OFFSET instead of fixed offset.
(pa_attr_length_call): Likewise.
(pa_attr_length_indirect_call): Likewise.
Index: config/pa/pa.c
===
--- config/pa/pa.c (revision 188142)
+++ config/pa/pa.c (working copy)
@@ -7457,7 +7457,7 @@
return 24;
else
{
- if (!TARGET_LONG_CALLS && distance < 24)
+ if (!TARGET_LONG_CALLS && distance < MAX_PCREL17F_OFFSET)
return 8;
if (TARGET_LONG_ABS_CALL && !flag_pic)
@@ -7670,7 +7670,7 @@
/* pc-relative branch. */
if (!TARGET_LONG_CALLS
&& ((TARGET_PA_20 && !sibcall && distance < 760)
- || distance < 24))
+ || distance < MAX_PCREL17F_OFFSET))
length += 8;
/* 64-bit plabel sequence. */
@@ -8029,7 +8029,7 @@
if (TARGET_FAST_INDIRECT_CALLS
|| (!TARGET_PORTABLE_RUNTIME
&& ((TARGET_PA_20 && !TARGET_SOM && distance < 760)
- || distance < 24)))
+ || distance < MAX_PCREL17F_OFFSET)))
return 8;
if (flag_pic)
Index: config/pa/pa.h
===
--- config/pa/pa.h (revision 188142)
+++ config/pa/pa.h (working copy)
@@ -1519,3 +1519,12 @@
#undef TARGET_HAVE_TLS
#define TARGET_HAVE_TLS true
#endif
+
+/* The maximum offset in bytes for a PA 1.X pc-relative call to the
+ head of the preceding stub table. The selected offsets have been
+ chosen so that approximately one call stub is allocated for every
+ 86.7 instructions. A long branch stub is two instructions when
+ not generating PIC code. For HP-UX and ELF targets, PIC stubs are
+ seven and four instructions, respectively. */
+#define MAX_PCREL17F_OFFSET \
+ (flag_pic ? (TARGET_HPUX ? 198164 : 221312) : 24)
Re: [google] Add options to pattern match function name for hotness attributes
Thank you guys for the comments, I'll update the patch to : 1. generalize the flag to enable other annotations such always_inline. 2. change to use deferred option. Thanks, Dehao On Sun, Jun 3, 2012 at 12:40 PM, Xinliang David Li wrote: > On Sat, Jun 2, 2012 at 11:11 AM, Jan Hubicka wrote: >>> Actually Dehao also plans to teach the static predictor to understand >>> standard library functions more (e.g IO functions) and add more naming >> >> How this differ from annotating the library? > > I find them more suitable to be compiler heuristic than being > function's attribute -- attribute is a much stronger assertion. > >> >> There are indeed quite some possibilities to do about library calls >> >> One thing I always wondered about is how to tell predictor that paths >> containing >> heavy IO functions don't need to be really opimized to death, since their >> execution >> time is dominated by the IO... >> > > Yes -- if branch predictor does the right thing and if function > splitter is powerful enough, the IO code can be outlined and optimized > for size :) > > >>> based heuristics such as 'error, success, failure, fatal etc). >> >> yeah, this is also mentioned by some branch prediction papers. It is bit >> kludgy >> in nature (i.e. it won't understand programs written in Czech language) but >> it >> is an heuristics after all. >> > > right. > > thanks, > > David > >> Honza >>> >>> thanks, >>> >>> David >>> >>> > Honza >>> >> >>> >> thanks, >>> >> >>> >> David >>> >> > Honza
Re: [gcov] a few improvements
On 06/03/12 05:51, Xinliang David Li wrote: On Fri, Dec 30, 2011 at 10:25 AM, Nathan Sidwell wrote: I've committed this patch to fix and improve coverage reporting: 1) the time stamp local_tick will be -1 if the user overrides the random seed. In such cases the gcov data file should be deleted, just as it would if the time cannot be determined. The end result is that after a the profile data is used in the compilation (with option -fprofile-use -frandom-seed=), it is then deleted. Is this intended? This basically makes FDO very hard to use when -frandom-seed is used. IIUC the file is deleted after being used. What is the problem you are encountering? (if you are having a problem, that suggests others on systems without local_tick are also having problems) nathan
Document sincos standard pattern name
Hi,
The attached patch adds some documentation for the sincos standard
pattern name. Tested with 'make info dvi pdf'.
Is the text correct and OK to apply?
Maybe it would also make sense to apply it to the 4.7 branch?
Cheers,
Oleg
ChangeLog:
* gcc/doc/md.texi (Standard Pattern Names For Generation):
Document sincos pattern.
Index: gcc/doc/md.texi
===
--- gcc/doc/md.texi (revision 188148)
+++ gcc/doc/md.texi (working copy)
@@ -4795,6 +4795,22 @@
built-in function uses the mode which corresponds to the C data
type @code{float}.
+@cindex @code{sincos@var{m}3} instruction pattern
+@item @samp{sincos@var{m}3}
+Store the sine of operand 2 into operand 0 and the cosine of
+operand 2 into operand 1.
+
+The @code{sin} and @code{cos} built-in functions of C always use the
+mode which corresponds to the C data type @code{double} and the
+@code{sinf} and @code{cosf} built-in function use the mode which
+corresponds to the C data type @code{float}.
+Targets that can calculate the sine and cosine simultaneously can
+implement this pattern as opposed to implementing individual
+@code{sin@var{m}2} and @code{cos@var{m}2} patterns. The @code{sin}
+and @code{cos} built-in functions will then be expanded to the
+@code{sincos@var{m}3} pattern, with one of the output values
+left unused.
+
@cindex @code{exp@var{m}2} instruction pattern
@item @samp{exp@var{m}2}
Store the exponential of operand 1 into operand 0.
Re: [Fortran, DRAFT patch] PR 46321 - [OOP] Polymorphic deallocation
> Right, the problem is that the _free component is missing. Just as the > _copy component, _free should be present for *every* vtype, no matter > if there are allocatable components or not. If the _free component is > not needed, it should be initialized to EXPR_NULL. With an "empty" _free function for every type which does not have allocatable components the problem with dynamic_dispatch_4.f03 disappears :), thank you very much. In the afternoon I'll reorganize the code. Bye. Alessandro
Re: [Fortran, patch] PR 48831 - Constant expression (PARAMETER array element) rejected as nonconstant
Hi all,
in attachment the patch which includes the review comments provided by Tobias.
The patch is bootstrapped and tested on x86_64-unknown-linux-gnu.
Regards.
Alessandro
2012/5/20 Tobias Burnus :
> Hi Alessandro,
>
>
> Alessandro Fanfarillo wrote:
>>
>> in attachment there's a patch for PR 48831, it also includes a new
>> test case suggested by Tobias Burnus.
>> The patch is bootstrapped and tested on x86_64-unknown-linux-gnu.
>
>
> Please try to ensure that your patch has a text mime type - it shows up as
> Content-Type: application/octet-stream;
> which makes reading, reviewing and quoting your patch more difficult.
>
> PR fortran/48831
> * gfortran.h: Add non-static prototype declaration
> of check_init_expr function.
> * check.c (kind_check): Change if condition related
> to check_init_expr.
> * expr.c: Remove prototype declaration of
> check_init_expr function and static keyword.
>
>
> You should add the name of the function you change in parentheses, e.g.
>
> * gfortran.h (check_init_expr): Add prototype declaration of function.
>
> (The "non-static" is superfluous as static functions shouldn't be in header
> files.) For "check_init_expr" I'd use "Remove forward declaration" instead
> of "Remove prototype declaration" but that's personal style. But again, you
> should include the function name in parentheses. The reason is that one can
> more quickly find it, if it is always at the same spot.
>
> As mentioned before, the gfortran convention is to prefix functions (gfc_) -
> at least those which are nonstatic. Please change the function name.
>
> - if (k->expr_type != EXPR_CONSTANT)
> + if (check_init_expr(k) != SUCCESS)
>
>
> GNU style: Add a space before the "(" of the function argument:
> "check_init_expr (k)".
>
>
> +/* Check an intrinsic arithmetic operation to see if it is consistent
> + with some type of expression. */
> +gfc_try check_init_expr (gfc_expr *);
>
>
>
> I have to admit that after reading only the comment, I had no idea what the
> function does - especially the "some type" is not really helpful. How about
> a simple "Check whether an expression is an initialization/constant
> expression." Initialization and constant expressions are well defined in
> the Fortran standard. (Actually, I find the function name speaks already for
> itself, thus, I do not see the need for a comment, but I also do not mind a
> comment.)
>
> (One problem with the name "constant expression" vs. "initialization
> expression" is that Fortran 90/95 distinguish between them while Fortran
> 2003/2008 have merged them to a single type of expression; Fortran 2003
> calls the merged expression type "initialization expression" while Fortran
> 2008 calls them "constant expressions". In principle, gfortran should make
> the distinction with -std=f95 and reject expressions which are nonconstant
> and only initexpressions when the standard demands it, but I am not sure
> whether gfortran does. That part of gfortran is a bit unclean and the
> distinction between init/const expr is nowadays largely ignored by the
> gfortran developers.)
>
> Otherwise, the patch looks OK.
>
> Tobias
2012-06-03 Alessandro Fanfarillo
Tobias Burnus
PR fortran/48831
* gfortran.h (check_init_expr): Add prototype declaration
of function.
* check.c (kind_check): Change if condition related
to check_init_expr.
* expr.c (check_init_expr): Remove forward declaration
and static keyword. Change name in gfc_check_init_expr.
2012-06-03 Alessandro Fanfarillo
PR fortran/48831
* gfortran.dg/parameter_array_element_2.f90: New.
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (revisione 188147)
+++ gcc/fortran/expr.c (copia locale)
@@ -1943,12 +1943,6 @@
}
-/* Check an intrinsic arithmetic operation to see if it is consistent
- with some type of expression. */
-
-static gfc_try check_init_expr (gfc_expr *);
-
-
/* Scalarize an expression for an elemental intrinsic call. */
static gfc_try
@@ -1994,7 +1988,7 @@
for (; a; a = a->next)
{
/* Check that this is OK for an initialization expression. */
- if (a->expr && check_init_expr (a->expr) == FAILURE)
+ if (a->expr && gfc_check_init_expr (a->expr) == FAILURE)
goto cleanup;
rank[n] = 0;
@@ -2231,7 +2225,7 @@
gfc_actual_arglist *ap;
for (ap = e->value.function.actual; ap; ap = ap->next)
-if (check_init_expr (ap->expr) == FAILURE)
+if (gfc_check_init_expr (ap->expr) == FAILURE)
return MATCH_ERROR;
return MATCH_YES;
@@ -2319,7 +2313,7 @@
&ap->expr->where);
return MATCH_ERROR;
}
- else if (not_restricted && check_init_expr (ap->expr) == FAILURE)
+ else if (not_restricted && gfc_check_init_expr (ap->expr) == FAILURE)
return MATCH_ERROR;
RFA: Alternative iterator implementation
As discussed in the context of the AARCH64 submission, this patch
rewrites the iterator handling in read-rtl.c so that we record
iterator positions using an on-the-side VEC rather than placeholder
modes and codes. We then substitute in-place for each sequence of
iterator values and take a deep copy of the result. We do any string
substitutions during the copy.
The patch also generalises the current use of attributes for rtx modes
("(zero_extend: ...)", etc.) so that the same kind of thing
can be done with future iterator types, including the int iterators.
Not sure whether that'll be useful or not, but it made the patch
easier to write.
Tested by making sure that the insn-*.c output didn't change for
x86_64-linux-gnu, except that we now do a better job of retaining
#line information (not seen as a good thing by everbody, I realise).
Also made sure that things like insn-output.c are still generated
in the blink of an eye.
Bootstrapped & regression-tested on x86_64-linux-gnu and i686-pc-linux-gnu.
OK to install?
Richard
gcc/
* read-rtl.c (mapping): Remove index field. Add current_value field.
Define heap vectors.
(iterator_group): Fix long line. Remove num_builtins field and
uses_iterator fields. Make apply_iterator take a void * parameter.
(iterator_use, atttribute_use): New structures.
(iterator_traverse_data, BELLWETHER_CODE, bellwether_codes): Delete.
(current_iterators, iterator_uses, attribute_uses): New variables.
(uses_mode_iterator_p, uses_code_iterator_p): Delete.
(apply_mode_iterator, apply_code_iterator): Take a void * parameter.
(map_attr_string, apply_iterator_to_string): Remove iterator
and value parameters. Look through all current iterator values
for a matching attribute.
(mode_attr_index, apply_mode_maps): Delete.
(apply_iterator_to_rtx): Replace with...
(copy_rtx_for_iterators): ...this new function.
(uses_iterator_p, apply_iterator_traverse): Delete.
(apply_attribute_uses, add_current_iterators, apply_iterators): New
functions.
(add_mapping): Remove index field. Set current_value field.
(initialize_iterators): Don't set num_builtins and uses_iterator_p
fields.
(find_iterator): Delete.
(record_iterator_use, record_attribute_use): New functions.
(record_potential_iterator_use): New function.
(check_code_iterator): Remove handling of bellwether codes.
(read_rtx): Remove mode maps. Truncate iterator and attribute uses.
(read_rtx_code, read_nested_rtx, read_rtx_variadic): Remove mode_maps
parameter. Use the first code iterator value instead of the
bellwether_codes array. Use record_potential_iterator_use
for modes.
Index: gcc/read-rtl.c
===
--- gcc/read-rtl.c 2012-06-03 08:58:32.251211521 +0100
+++ gcc/read-rtl.c 2012-06-03 09:20:47.633208254 +0100
@@ -41,7 +41,7 @@ struct map_value {
};
/* Maps an iterator or attribute name to a list of (integer, string) pairs.
- The integers are mode or code values; the strings are either C conditions
+ The integers are iterator values; the strings are either C conditions
or attribute values. */
struct mapping {
/* The name of the iterator or attribute. */
@@ -50,82 +50,80 @@ struct mapping {
/* The group (modes or codes) to which the iterator or attribute belongs. */
struct iterator_group *group;
- /* Gives a unique number to the attribute or iterator. Numbers are
- allocated consecutively, starting at 0. */
- int index;
-
/* The list of (integer, string) pairs. */
struct map_value *values;
+
+ /* For iterators, records the current value of the iterator. */
+ struct map_value *current_value;
};
-/* A structure for abstracting the common parts of code and mode iterators. */
+/* Vector definitions for the above. */
+typedef struct mapping *mapping_ptr;
+DEF_VEC_P (mapping_ptr);
+DEF_VEC_ALLOC_P (mapping_ptr, heap);
+
+/* A structure for abstracting the common parts of iterators. */
struct iterator_group {
- /* Tables of "mapping" structures, one for attributes and one for iterators.
*/
+ /* Tables of "mapping" structures, one for attributes and one for
+ iterators. */
htab_t attrs, iterators;
- /* The number of "real" modes or codes (and by extension, the first
- number available for use as an iterator placeholder). */
- int num_builtins;
-
- /* Treat the given string as the name of a standard mode or code and
+ /* Treat the given string as the name of a standard mode, etc., and
return its integer value. */
int (*find_builtin) (const char *);
- /* Return true if the given rtx uses the given mode or code. */
- bool (*uses_iterator_p) (rtx, int);
+ /* Make the given pointer use the given iterator value. */
+ void (*apply_iterator) (void *, int);
Re: [PATCH 2/2] mips: Add R4700 scheduling support
Matt Turner writes: > The R4700 is identical to the R4600 except for the integer and > floating-point multiplication costs. > > See page 4 of http://datasheets.chipdb.org/IDT/MIPS/79RV4700.pdf > > 2012-03-24 Matt Turner > > gcc/ > * config/mips/4600.md (r4700_imul_si): New. > (r4700_imul_di): New. > (r4700_fmul_single): New. > (r4700_fmul_double): New. > * config/mips/mips-cpus.def: Add r4700. > * config/mips/mips.c: Likewise. > * config/mips/mips.md: Likewise. > * config/mips/mips-tables.opt: Regenerate. Applied, thanks. Richard
