[SH] PR 51244 - Add nott insn

[Oleg Endo]

Hello,

The attached patch adds the 'nott' insn that is supported by SH2A.
While the 'nott' pattern itself is usually combined away entirely (CSiBE
shows no diffs for SH2A), on non-SH2A the new patterns seem to catch a
few border cases, where unnecessary movt sequences can be eliminated.

Tested against rev 189338 with 
make -k check RUNTESTFLAGS="--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m2a-single/-mb,-m4/-ml,-m4/-mb,
-m4-single/-ml,-m4-single/-mb,-m4a-single/-ml,-m4a-single/-mb}"

and no new failures.

Cheers,
Oleg

ChangeLog:

* config/sh/sh.md (*branch_true_eq, *branch_false_ne, nott):
New insns.
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md	(revision 189269)
+++ gcc/config/sh/sh.md	(working copy)
@@ -7220,6 +7220,17 @@
 }
   [(set_attr "type" "cbranch")])
 
+(define_insn "*branch_true_eq"
+  [(set (pc) (if_then_else (eq (match_operand 1 "t_reg_operand" "")
+			   (const_int 1))
+			   (label_ref (match_operand 0 "" ""))
+			   (pc)))]
+  "TARGET_SH1"
+{
+  return output_branch (1, insn, operands);
+}
+  [(set_attr "type" "cbranch")])
+
 (define_insn "branch_false"
   [(set (pc) (if_then_else (eq (match_operand 1 "t_reg_operand" "")
 			   (const_int 0))
@@ -7231,6 +7242,17 @@
 }
   [(set_attr "type" "cbranch")])
 
+(define_insn "*branch_false_ne"
+  [(set (pc) (if_then_else (ne (match_operand 1 "t_reg_operand" "")
+			   (const_int 1))
+			   (label_ref (match_operand 0 "" ""))
+			   (pc)))]
+  "TARGET_SH1"
+{
+  return output_branch (0, insn, operands);
+}
+  [(set_attr "type" "cbranch")])
+
 ;; Patterns to prevent reorg from re-combining a condbranch with a branch
 ;; which destination is too far away.
 ;; The const_int_operand is distinct for each branch target; it avoids
@@ -9844,6 +9866,20 @@
   ""
   [(const_int 0)])
 
+(define_insn_and_split "nott"
+  [(set (reg:SI T_REG) (xor:SI (reg:SI T_REG) (const_int 1)))]
+  "TARGET_SH1"
+{
+  gcc_assert (TARGET_SH2A);
+  return "nott";
+}
+  "! TARGET_SH2A && can_create_pseudo_p ()"
+  [(set (match_dup 0) (reg:SI T_REG))
+   (set (reg:SI T_REG) (eq:SI (match_dup 0) (const_int 0)))]
+{
+  operands[0] = gen_reg_rtx (SImode);
+})
+
 (define_expand "cstoresf4"
   [(set (match_operand:SI 0 "register_operand" "=r")
 	(match_operator:SI 1 "sh_float_comparison_operator"

[patch] PR53881

[Steven Bosscher]

Hello,

I was relying on the assumption that all case labels in a switch
vector that jump to the same target block would also have the same
CASE_LABEL. This isn't so for the test case of PR53881, where DCE
removes a dead statement but preserves a user label. Fortunately,
using find_edge in emit_case_bit_tests is cheap because we know that
there are very few edges going out of the switch (at most 3) and
usually only one incoming edge per case target.

Bootstrapped on powerpc64-unknown-linux-gnu. Committed as obvious (r189349).

Ciao!
Steven

gcc/
PR tree-optimization/53881
* tree-switch-conversion.c (emit_case_bit_tests): Do not rely on
comparing labels to establish uniqueness of a switch case target,
use the CFG instead.

testsuite/
PR tree-optimization/53881
* gcc.dg/pr53881.c: New test.

Index: gcc/tree-switch-conversion.c
--- trunk/gcc/tree-switch-conversion.c  2012/07/07 12:27:33 189348
+++ trunk/gcc/tree-switch-conversion.c  2012/07/07 12:35:44 189349
@@ -329,14 +329,13 @@
   unsigned int lo, hi;
   tree cs = gimple_switch_label (swtch, i);
   tree label = CASE_LABEL (cs);
+  edge e = find_edge (switch_bb, label_to_block (label));
   for (k = 0; k < count; k++)
-   if (label == test[k].label)
+   if (e == test[k].target_edge)
  break;

   if (k == count)
{
- edge e = find_edge (switch_bb, label_to_block (label));
- gcc_assert (e);
  gcc_checking_assert (count < MAX_CASE_BIT_TESTS);
  test[k].hi = 0;
  test[k].lo = 0;

[RFT] Remove -fno-tree-dominator-opts from libgcc/config/t-darwin

[Steven Bosscher]

Hello,


PR26840 was fixed long ago so this work-around shouldn't be necessary anymore:

Index: ../libgcc/config/t-darwin
===
--- ../libgcc/config/t-darwin   (revision 189348)
+++ ../libgcc/config/t-darwin   (working copy)
@@ -1,7 +1,5 @@
-# Pass -fno-tree-dominator-opts to work around bug 26840.
 crt3.o: $(srcdir)/config/darwin-crt3.c
-   $(crt_compile) \
- -fno-tree-dominator-opts $(DARWIN_EXTRA_CRT_BUILD_CFLAGS) -c $<
+   $(crt_compile) -fno-tree-dominator-opts
$(DARWIN_EXTRA_CRT_BUILD_CFLAGS) -c $<

 crttms.o: $(srcdir)/config/darwin-crt-tm.c
$(crt_compile) $(DARWIN_EXTRA_CRT_BUILD_CFLAGS) -DSTART -c $<


Request for testing because I have no access to a Darwin machine.

Thanks,

Ciao!
Steven

Re: [patch][RFC] Remove tree/gimple/rtl dependencies from core CFG code

[Steven Bosscher]

On Fri, Jul 6, 2012 at 8:29 AM, Steven Bosscher  wrote:
> On Fri, Jul 6, 2012 at 1:06 AM, Joseph S. Myers  
> wrote:
>> My only comment is that you add a coretypes.h include to tree-flow.h and
>> remove one from tree-ssa-alias.h - but since the GCC convention is that
>> all .c files start with includes of config.h, system.h and coretypes.h in
>> that order, the include in tree-flow.h shouldn't be needed - any source
>> file including tree-flow.h should have included coretypes.h before
>> tree-flow.h.  (That is, I think any include of coretypes.h from another .h
>> file, except probably for the special case of gcc-plugin.h, is suspect
>> unless we decide to change the convention.)
>
> Agreed. I thought, too, that this is the convention, and was surprised
> to find coretypes.h included in another header.

BTW, why do so many libgcc files include coretypes.h?

As far as I can tell, only libgcc/config/tilepro/atomic.c actually
uses types defined in coretypes.h (it uses memmodel and IMHO that'd be
a bug).

Ciao!
Steven

Re: [RFT] Remove -fno-tree-dominator-opts from libgcc/config/t-darwin

[H.J. Lu]

On Sat, Jul 7, 2012 at 7:48 AM, Steven Bosscher  wrote:
> Hello,
>
>
> PR26840 was fixed long ago so this work-around shouldn't be necessary anymore:
>
> Index: ../libgcc/config/t-darwin
> ===
> --- ../libgcc/config/t-darwin   (revision 189348)
> +++ ../libgcc/config/t-darwin   (working copy)
> @@ -1,7 +1,5 @@
> -# Pass -fno-tree-dominator-opts to work around bug 26840.
>  crt3.o: $(srcdir)/config/darwin-crt3.c
> -   $(crt_compile) \
> - -fno-tree-dominator-opts $(DARWIN_EXTRA_CRT_BUILD_CFLAGS) -c $<
> +   $(crt_compile) -fno-tree-dominator-opts
> $(DARWIN_EXTRA_CRT_BUILD_CFLAGS) -c $<
>

Are you sure this the right patch? -fno-tree-dominator-opts is still here.

-- 
H.J.

Re: [RFT] Remove -fno-tree-dominator-opts from libgcc/config/t-darwin

[Steven Bosscher]

On Sat, Jul 7, 2012 at 5:06 PM, H.J. Lu  wrote:
> Are you sure this the right patch? -fno-tree-dominator-opts is still here.

I am sure it is not the right patch :-)
Thanks!

Index: libgcc/config/t-darwin
===
--- libgcc/config/t-darwin  (revision 189348)
+++ libgcc/config/t-darwin  (working copy)
@@ -1,7 +1,5 @@
-# Pass -fno-tree-dominator-opts to work around bug 26840.
 crt3.o: $(srcdir)/config/darwin-crt3.c
-   $(crt_compile) \
- -fno-tree-dominator-opts $(DARWIN_EXTRA_CRT_BUILD_CFLAGS) -c $<
+   $(crt_compile) $(DARWIN_EXTRA_CRT_BUILD_CFLAGS) -c $<

 crttms.o: $(srcdir)/config/darwin-crt-tm.c
$(crt_compile) $(DARWIN_EXTRA_CRT_BUILD_CFLAGS) -DSTART -c $<

Re: [patch][RFC] Remove tree/gimple/rtl dependencies from core CFG code

[Joseph S. Myers]

On Sat, 7 Jul 2012, Steven Bosscher wrote:

> BTW, why do so many libgcc files include coretypes.h?

It might be needed for the tm.h includes, if tm.h uses types from 
coretypes.h - there are still a fair number of host-side tm.h macros used 
in libgcc, that need to transition to libgcc-only target macros or macros 
predefined by the compiler.

-- 
Joseph S. Myers
jos...@codesourcery.com

[patch] Define GENERATOR_FILE explicitly for the host gengtype objects

[Steven Bosscher]

Hello,

Since r177358, a host executable gengtype is built so that plugins can
use the GTY markers.

Even for the host, gengtype is a GENERATOR_FILE, but since the build-%
rule doesn't apply to host objects, gengtype was being built without
it. So when I removed coretypes.h from double-int.h, my build failed.

Fixed by adding -DGENERATOR_FILE explicitly to the host gengtype*.o objects.

Bootstrapped on powerpc64-unknown-linux-gnu. OK for trunk?

Ciao!
Steven

* Makefile.in (gengtype-lex.o, gengtype-parse.o, gengtype-state.o,
gengtype.o): Add -DGENERATOR_FILE manually for host gengtype objects.

Index: Makefile.in
===
--- Makefile.in (revision 189348)
+++ Makefile.in (working copy)
@@ -3818,23 +3818,40 @@ build/genextract.o : genextract.c $(RTL_BASE_H) $(
 build/genflags.o : genflags.c $(RTL_BASE_H) $(OBSTACK_H) $(BCONFIG_H)  \
   $(SYSTEM_H) coretypes.h $(GTM_H) errors.h $(READ_MD_H) gensupport.h
 build/gengenrtl.o : gengenrtl.c $(BCONFIG_H) $(SYSTEM_H) rtl.def
+
+# The gengtype generator program is special: Two versions are built.
+# One is for the build machine, and one is for the host to allow
+# plugins to define their types and generate the supporting GGC
+# datastructures and routines with GTY markers.
+# The host object files depend on CONFIG_H, and the build objects
+# on BCONFIG_H.  For the build objects, add -DGENERATOR_FILE manually,
+# the build-%: rule doesn't apply to them.
+
 gengtype-lex.o build/gengtype-lex.o : gengtype-lex.c gengtype.h $(SYSTEM_H)
 gengtype-lex.o: $(CONFIG_H)
+CFLAGS-gengtype-lex.o += -DGENERATOR_FILE
 build/gengtype-lex.o: $(BCONFIG_H)
+
 gengtype-parse.o build/gengtype-parse.o : gengtype-parse.c gengtype.h \
   $(SYSTEM_H)
 gengtype-parse.o: $(CONFIG_H)
+CFLAGS-gengtype-parse.o += -DGENERATOR_FILE
 build/gengtype-parse.o: $(BCONFIG_H)
+
 gengtype-state.o build/gengtype-state.o: gengtype-state.c $(SYSTEM_H) \
   gengtype.h errors.h double-int.h version.h $(HASHTAB_H) $(OBSTACK_H) \
   $(XREGEX_H)
 gengtype-state.o: $(CONFIG_H)
+CFLAGS-gengtype-state.o += -DGENERATOR_FILE
 build/gengtype-state.o: $(BCONFIG_H)
+
 gengtype.o build/gengtype.o : gengtype.c $(SYSTEM_H) gengtype.h\
   rtl.def insn-notes.def errors.h double-int.h version.h $(HASHTAB_H) \
   $(OBSTACK_H) $(XREGEX_H)
 gengtype.o: $(CONFIG_H)
+CFLAGS-gengtype.o += -DGENERATOR_FILE
 build/gengtype.o: $(BCONFIG_H)
+
 build/genmddeps.o: genmddeps.c $(BCONFIG_H) $(SYSTEM_H) coretypes.h\
   errors.h $(READ_MD_H)
 build/genmodes.o : genmodes.c $(BCONFIG_H) $(SYSTEM_H) errors.h
\

[patch] Never include coretypes.h in another header file

[Steven Bosscher]

Hello,

As suggested by Joseph. Subject says all. This turned out to be easier
than I expected: Almost all Makefile rules already include
coretypes.h, I only had to adjust something for realmpfr.o.

Bootstrapped on x86_64-unknown-linux-gnu. OK for trunk?

Ciao!
Steven


no_coretypes_in_headers.diff
Description: Binary data

Re: [v3] PR 53270 fix hppa-linux bootstrap regression

[Jonathan Wakely]

On 14 June 2012 23:23, Jonathan Wakely wrote:
> We've known for ages that it's not portable to do:
>
> __gthread_mutex_t tmp = __GTHREAD_MUTEX_INIT;
> _M_mutex = __tmp;
>
> As PR 53270 shows, the copy assignment now actually fails in C++11
> mode on platforms using LinuxThreads, because the mutex has a volatile
> member so in C++11 mode the copy assignment operator is deleted.
>
> This patch changes  to use a
> brace-or-equals-initializer for the mutexes and condition variable in
> C++11 mode, allowing hppa-linux to bootstrap again and avoiding the
> non-portable construct everywhere (this is already the approach we
> take for std::mutex etc. in ). It also makes the same change to
> the mutex used in  and fixes a resource leak in that header
> by ensuring the mutex is destroyed when it was initialized by
> __gthread_mutex_init_function.
>
> PR libstdc++/53270
> * include/ext/concurrence.h (__mutex, __recursive_mutex, __cond): Use
> NSDMI in C++11 mode.
> * include/ext/rope (_Refcount_Base): Likewise. Destroy mutex in
> destructor when initialized by function.
>
> Tested x86_64-linux, powerpc64-linux, hppa-linux and x86_64-netbsd (on
> the 4.7 branch instead, as netbsd doesn't bootstrap at the moment.)
> Committed to trunk.

I've come to the conclusion it would be better to use NSDMIs even in
C++98 mode, which works as a GCC extension, without a warning in
system headers.  This means using -Wsystem-headers -pedantic-errors
breaks libstdc++, but that's already the case for our uses of variadic
templates in C++98 mode.

The attached patch does that, any objections to me committing it to trunk?

Jason, I assume it's safe to rely on NSDMI working correctly in C++98
mode, or you'd have made it an error not a warning?

> For 4.6.4 and 4.7.2 I plan to make a less intrusive change, #undef'ing
> the __GTHREAD_MUTEX_INIT, _GTHREAD_RECURSIVE_MUTEX_INIT and
> __GTHREAD_COND_INIT macros on hppa-linux in C++11 mode, so that the
> init functions are used instead.  This fixes the bootstrap regression
> on hppa-linux without affecting other targets.

I've struggled to fix this on the release branches in a clean way.

Currently on the 4.7 branch config/os/gnu-linux/os_defines contains:

#if defined(__hppa__) && defined(__GXX_EXPERIMENTAL_CXX0X__)
# define _GTHREAD_USE_MUTEX_INIT_FUNC
# define _GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC
# define _GTHREAD_USE_COND_INIT_FUNC
#endif

Those macros instruct gthr-posix.h to suppress the definition of
__GTHREADS_xxx_INIT, forcing the definition and use of
__gthreads_xxx_init_function and __ghtreads_xxx_destroy instead.

This works, but it forces the use of the init functions even for NPTL,
and IIUC the bootstrap failure only occurs when using LinuxThreads.
(Dave said in the PR trail "I know parisc had switched to NPTL in
Debian lenny.")

Always using the init functions is sub-optimal when the macros would
work.  I think there's also a correctness issue on hppa-linux with
NPTL because of the change in behaviour: if a __gnu_cxx::__mutex is
initialized by code compiled with GCC 4.7.2 and then destroyed by code
compiled with GCC 4.5.4 it will be initialized by pthread_mutex_init
but pthread_mutex_destroy will not be called.  I don't believe that's
a problem for either LinuxThreads or NPTL, as the destroy functions
don't actually deallocate or clean up anything.

A better fix is tricky so I'd like some second opinions.

I added a check to acinclude.m4 and configure.ac to define a new macro
in c++config.h indicating the INIT macros fail in C++11 mode, which
would be set when using LinuxThreads and not when not using NPTL.  But
macros defined by configure.ac only come after os_defines.h is
included, so the new macro can't be used in os_defines.h to control
whether to define the _GTHREAD_USE_xxx_INIT_FUNC macros.

The new macro defined by configure.ac can't be used directly in
 e.g.

#if __GTHREADS && defined __GTHREADS_MUTEX_INIT \
  && ! defined _GLIBCXX_USE_GTHREAD_INIT_FUNCTIONS_FOR_CXX11

because that would try to use __GTHREADS_MUTEX_INIT_FUNCTION, but
gthr-posix.h only defines *either* the INIT macro *or* the
INIT_FUNCTION macro and associated function.

That means changes are needed to gthr-posix.h so that it
unconditionally defines the INIT_FUNCTIONs, in case some other code
wants to use that function even when the macro is available, as shown
above (this is option 5 below) or change gthr-posix.h so it knows
about the new macro in addition to all the other macros it already
knows about (this is options 6 and 7 below).

A different fix would be to make configure.ac define the
_GTHREADS_USE_xxx_INIT_FUNC macros, using the existing preprocessor
conditions in gthr-posix.h to force use of the init functions not the
macros.  AFAIK configure.ac can't define something conditionally on
C++98/C++11 mode, so that would be a change in behaviour for
hppa-linux using LinuxThreads in C++98 mode compared to GCC 4.5 (the
last release that bootstrapped on that plat

Re: User directed Function Multiversioning via Function Overloading (issue5752064)

[Xinliang David Li]

On Fri, Jul 6, 2012 at 11:05 PM, Jason Merrill  wrote:
> On 06/14/2012 04:13 PM, Sriraman Tallam wrote:
>>
>> C++ Frontend maintainers, Could you please take a look at the
>> front-end part when you find the time?
>
>
> It seems to me that what you have here are target-specific attributes that
> affect the signature of a function such that they make two declarations
> different that would otherwise declare the same function. Stepping away from
> the specific notion of versioning, it seems that these are the questions
> that you want the front end to be able to ask about these attributes:
>
> * Does this attribute affect a function signature?

The question becomes if a caller 'bar' with target attribute 'x' can
make a call to a function 'foo' with an incompatible target attribute
'y'. If the answer is no, then the target attribute is part of 'foo's
signature.  I think the answer is yes -- the attribute affects a
function signature.

> * Do the attributes on these two declarations make them different?

yes.

> * Do the attributes on these two declarations make one a better match?

yes -- and there are rules defined for that.

> * Given a call to function X, should I call another function instead?

The binding can happen at compile time (given caller/callee attribute)
or at the runtime.

> * Return a string representation of the attributes on this function that
> affect its signature.

yes.

>
> Does this seem like a worthwhile direction to other people, or do you like
> better the approach the patch takes, handling versioning directly?

There are prior discussions about this. The direct way of handling it
is to use __builtin_dispatch, but we concluded that using function
overloading is much more user friendly. Note that Intel's icc has a
similar feature to the overloading approach implemented by Sri here.

thanks,

David
>
> Jason

[patch][fortran] Include coretypes.h in .c files, not in gfortran.h

[Steven Bosscher]

Hello,

Currently, gcc/flags.h and fortran/gfortran.h both include
coretypes.h. In many fortran/*.c files, flags.h is included before
gfortran.h, so when flags.h no longer includes coretypes.h (xf.
http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00275.html) gfortran no
longer builds without some changes.

I must say, I am surprised that gfortran.h includes coretypes.h. The
idea always was to try and keep the front end and the back end as much
separated as possible, and including coretypes.h in the most important
front-end header doesn't fit in that picture.  I initially tried to
just stop including flags.h in e.g. fortran/arith.c because I couldn't
think of anything that arith.h should know from flags.h, but that
breaks the build because arith.c looks at 'pedantic' from the
generated file options.h. Next, I considered adding pedantic to
gfc_options, but that, of course, clashes with the define in options.h
(it's a macro so a field named 'pedantic' in gfc_options isn't
possible. Oh well... I've added removing the middle-end dependencies
from the front end to my TODO list.

For now, the solution I disliked the least is to include coretypes.h
explicitly in the C files that need it. It really doesn't change
anything (gfortran.h already included it) but it makes this dependency
explicit, at least.

Bootstrapped&tested on powerpc64-unknown-linux-gnu and on
x86_64-unknown-linux-gnu, will commit in a few days.

Ciao!
Steven


fortran_coretypes.diff
Description: Binary data

Fix gcc.dg/lower-subreg-1.c failure, revisited.

[Hans-Peter Nilsson]

> From: Richard Sandiford 
> Date: Wed, 9 May 2012 11:14:49 +0200

> Hans-Peter Nilsson  writes:
> >> From: Richard Sandiford 
> >> Date: Tue, 1 May 2012 16:46:38 +0200
> >
> >> To repeat: as things stand, very few targets define proper rtx costs
> >> for SET.
> >
> > IMHO it's wrong to start blaming targets when rtx_cost doesn't
> > take the mode in account in the first place, for the default
> > cost.  (Well, except for the modes-tieable subreg special-case.)
> > The targets where an operation in N * word_mode costs no more
> > than one in word_mode, if there even is one, is a minority,
> > let's adjust the defaults to that.
> 
> I'll pass on approving or disapproving this patch,

Here's an update.  Could you please reconsider?  I have to
appeal to your sense of fairness: after all you were involved in
the breaking patch.

> but for the record:
> a factor of word_mode seems a bit too simplistic.  It's OK for moves
> and logic ops, but addition of multiword modes is a bit more complicated.
> Multiplication and division by multiword modes is even more so, of course.

I adjusted multiplication and division to the more realistic
O(n*n).  That's just for show of course; we're comparing 2**2 to
instead of 2*2 as the focus is on the double size.  I did not
add specific adjustments for arithmetic codes not already there,
as I did not think such an adjustment to be appropriate.  The
intent is just to adapt the existing default costs to the change
of focus due to the lower-subreg change.  But if it's necessary
for approval, I'm willing to fix that.

> As things stand, rtx_cost is intentionally used for more than
> just valid target insns.  One of the main uses has always been
> to decide whether it is better to implement multiplications by a
> shift-and-add sequence, or whether to use multiplication instructions.
> The associated expmed code has never tried to decide which shifts are
> actually representable as matching rtl insns and which aren't.
> The same goes for division-using-multiplication.
> 
> So I think this patch

(referring to the commit that caused the major
gcc.dg/lower-subreg-1.c regression in May, not the predecessor
to *this* patch)

> is using rtx_cost according to its current
> interface.

Regardless of how "interface" is defined, that commit put much
more focus on the mode and made it about necessary to handle
SET, something that the default costs don't do without the patch
below.

> > Isn't the below better than doing virtually the same in each
> > target's rtx_costs?
> 
> FWIW, MIPS, SH and x86 all used something slightly different (and more
> complicated).  I imagine PowerPC and SPARC will too.  So "each" seems
> a bit strong.

Just strong enough: this patch indeed would have fixed the
gcc.dg/lower-subreg-1.c regression for MIPS and x86 (no
regressions) that was present at revision 187212, and no doubt
the predecessor patch too.  (I had to add commits 187299 and
187582 for MIPS and I couldn't get a baseline with java or
fortran enabled, thus --enable-languages=c,c++,lto,objc).  Also
similarly tested arm-eabi, sh-elf (though I couldn't repeat the
regression for those at the baseline) and cris-elf; no
regressions.  Fixes PR53176 for cris-elf.

Ok to commit?

* rtlanal.c (rtx_cost): Adjust default cost for X with a
UNITS_PER_WORD factor for all X according to the size of
its mode, not just for SUBREGs with untieable modes.
Handle SET.  Use factor * factor for MULT, DIV, UDIV,
MOD, UMOD.

Index: gcc/rtlanal.c
===
--- gcc/rtlanal.c   (revision 188403)
+++ gcc/rtlanal.c   (working copy)
@@ -3755,10 +3755,17 @@ rtx_cost (rtx x, enum rtx_code outer_cod
   enum rtx_code code;
   const char *fmt;
   int total;
+  int factor;
 
   if (x == 0)
 return 0;
 
+  /* A size N times larger than UNITS_PER_WORD likely needs N times as
+ many insns, taking N times as long.  */
+  factor = GET_MODE_SIZE (GET_MODE (x)) / UNITS_PER_WORD;
+  if (factor == 0)
+factor = 1;
+
   /* Compute the default costs of certain things.
  Note that targetm.rtx_costs can override the defaults.  */
 
@@ -3766,20 +3773,31 @@ rtx_cost (rtx x, enum rtx_code outer_cod
   switch (code)
 {
 case MULT:
-  total = COSTS_N_INSNS (5);
+  /* Multiplication has time-complexity O(N*N), where N is the
+number of units (translated from digits) when using
+schoolbook long multiplication.  */
+  total = factor * factor * COSTS_N_INSNS (5);
   break;
 case DIV:
 case UDIV:
 case MOD:
 case UMOD:
-  total = COSTS_N_INSNS (7);
+  /* Similarly, complexity for schoolbook long division.  */
+  total = factor * factor * COSTS_N_INSNS (7);
   break;
 case USE:
   /* Used in combine.c as a marker.  */
   total = 0;
   break;
+case SET:
+  /* A SET doesn't have a mode, so let's look at the SET_DEST to get
+the mode for the factor.

Re: [patch][fortran] Include coretypes.h in .c files, not in gfortran.h

[Steve Kargl]

On Sat, Jul 07, 2012 at 11:28:25PM +0200, Steven Bosscher wrote:
> 
> Currently, gcc/flags.h and fortran/gfortran.h both include
> coretypes.h. In many fortran/*.c files, flags.h is included before
> gfortran.h, so when flags.h no longer includes coretypes.h (xf.
> http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00275.html) gfortran no
> longer builds without some changes.
> 
> I must say, I am surprised that gfortran.h includes coretypes.h. The
> idea always was to try and keep the front end and the back end as much
> separated as possible, and including coretypes.h in the most important
> front-end header doesn't fit in that picture.  I initially tried to
> just stop including flags.h in e.g. fortran/arith.c because I couldn't
> think of anything that arith.h should know from flags.h, but that
> breaks the build because arith.c looks at 'pedantic' from the
> generated file options.h. Next, I considered adding pedantic to
> gfc_options, but that, of course, clashes with the define in options.h
> (it's a macro so a field named 'pedantic' in gfc_options isn't
> possible. Oh well... I've added removing the middle-end dependencies
> from the front end to my TODO list.
> 
> For now, the solution I disliked the least is to include coretypes.h
> explicitly in the C files that need it. It really doesn't change
> anything (gfortran.h already included it) but it makes this dependency
> explicit, at least.
> 
> Bootstrapped&tested on powerpc64-unknown-linux-gnu and on
> x86_64-unknown-linux-gnu, will commit in a few days.
> 

I think the correct fix is to remove the use of
pendantic in the gfortran FE.  



-- 
Steve

Ping again: [RFA:] Caveat for ARM in gcc-4.7/changes.html: unaligned accesses, take 2

[Hans-Peter Nilsson]

> From: Hans-Peter Nilsson 
> Date: Fri, 29 Jun 2012 15:06:44 +0200

> > From: Hans-Peter Nilsson 
> > Date: Fri, 22 Jun 2012 04:24:01 +0200
> 
> > > From: Hans-Peter Nilsson 
> > > Date: Fri, 15 Jun 2012 04:07:23 +0200
> > 
> > A ping.
> 
> And another ping, now CCing ARM maintainers,
> .

And another ping...

> > > Index: changes.html
> > > ===
> > > RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
> > > retrieving revision 1.113
> > > diff -p -u -r1.113 changes.html
> > > --- changes.html  5 Jun 2012 11:03:53 -   1.113
> > > +++ changes.html  15 Jun 2012 02:04:46 -
> > > @@ -43,6 +43,19 @@
> > >  
> > >  
> > >  
> > > +On ARM, when compiling for ARMv6 (but not ARMv6-M), ARMv7-A,
> > > +ARMv7-R, or ARMv7-M, the new option
> > > +-munaligned-access is active by default, which for
> > > +some source codes generates code that accesses memory on unaligned
> > > +adresses.  This will require the kernel of those systems to enable
> > > +such accesses (controlled by CP15 register c1, refer
> > > +to ARM documentation).  Alternatively or for compatibility with
> > > +kernels where unaligned accesses are not supported, all code has
> > > +to be compiled with -mno-unaligned-access.
> > > +Linux/ARM in official releases has automatically and
> > > +unconditionally supported unaligned accesses as emitted by GCC due
> > > +to this option being active since Linux version 2.6.28.
> > > +
> > >  Support on ARM for the legacy floating-point accelerator (FPA) 
> > > and
> > >  the mixed-endian floating-point format that it used has been 
> > > obsoleted.
> > >  The ports that still use this format have been obsoleted as well.

ping again - Show hash table stats when -fmem-report

[Dimitrios Apostolou]

Hi,

This patch adds many nice stats about hash tables when gcc is run with 
-fmem-report. Attached patch tested on x86, no regressions.


Also attached is sample output of -fmem-report when compiling reload.c 
with -O2 -g. Especially interesting is the extreme htab usage in 
var-tracking (ofcourse we already knew that... :-) and maybe symtab's 
slightly high collision rate (given it's a very hot hash table). Moreover 
it's notable that since last year, collision rate for mem_attrs_htab has 
been reduced from around 8 to 1, still not good enough but major 
improvement.


Jan: It has negligible overhead in runtime, that's why I'm pushing it 
again as it is. Having compile-time instrumentation is something 
different, but still I'm not quite sure if it's worth the effort. IMHO 
doing separate builds to get memory info is tedious and even I've stopped 
doing them. If it has no overhead maybe it's better as a runtime option?

Any way, compile-time instrumentation can come later.

Finally I repost some of my notes I'd like to get feedback on:

* Is it OK that I included  in libiberty's hashtab.c? What's the 
proper way to assert stuff, since gcc_assert() is not accessible?


* Many hash tables are created with htab_create_ggc(), for example 
referenced_vars and default_defs in tree-ssa.c. I collect statistics in 
delete_tree_ssa() but maybe some are not deallocated in there but 
automatically garbage collected?


* Obviously hash table sizes are inflated where two entries might 
reference the same element (for example in symtab_hash) but I don't handle 
this.


* Changes that reduce load factor have been backed out since they brought 
controversy. I still think they are good, at least for symtab. I'll 
measure numbers separately for this after this patch makes it.



Thanks,
Dimitris

dwarf2out.c: file_table hash table statistics:
slots   251
used98 (39.04%)
valid   98
deleted 0
total size  1852  B
struct htab 64   B
table   1004 B
one element 8B
all elements784  B
expansions  2
searches8788
collisions  4239
coll/search 0.4824
Number of expanded macros: 23596
Average number of tokens per macro expansion: 10

Line Table allocations during the compilation process
Number of ordinary maps used:  498 
Ordinary map used size: 11k
Number of ordinary maps allocated:1365 
Ordinary maps allocated size:   31k
Number of macro maps used:  20k
Macro maps used size:  499k
Macro maps locations size:2059k
Macro maps size:  2558k
Duplicated maps locations size:767k
Total allocated maps size:2603k
Total used maps size: 2570k

Memory still allocated at the end of the compilation process
Size   AllocatedUsedOverhead
8556k555k 13k
16  1368k   1365k 21k
32  1736k   1727k 20k
64   212k209k   2120 
128 1400k   1398k 12k
256 1520k   1515k 11k
512 1128k   1123k   9024 
1024 444k394k   3552 
2048 320k298k   2560 
4096 252k 76k   2016 
8192 272k240k   1088 
16384848k352k   1696 
32768288k288k288 
65536128k 64k 64 
131072128k  0  32 
262144256k  0  32 
524288512k512k 32 
12  5104k   5097k 89k
20   404k400k   5656 
24  4820k   4797k 61k
28  3140k   3130k 36k
36  1208k   1196k 12k
40   344k341k   3784 
44  1200k   1196k 11k
48  2648k   2636k 25k
52   384k378k   3840 
56  1544k   1522k 15k
6092k 88k920 
108  348k338k   3132 
84  2640k   2597k 23k
96  2844k   2796k 24k
92   432k342k   3888 
68   804k798k   7236 
176  624k606k   4992 
100   20k 13k180 
Total 39M 37M435k

libcpp symtab string pool:
identifiers 32361 (100.00%)
entries 32361 (49.38%)
deleted 0
slots   65536
string bytes507k (4064  obstack_memory_used)
table size  256k
expansions  2
searches228153
collisions  145056
coll/search 0.6358
ins/search  0.1418
avg. entry  16

PR #53525 - track-macro-expansion performance regression

[Dimitrios Apostolou]

With the attached patches I introduce four new obstacks in struct 
cpp_reader to substitute malloc's/realloc's when expanding macros. Numbers 
have been posted in the PR, but to summarize:


before: 0.785 s or  2201 M instr
after:  0.760 s or  2108 M instr

Memory overhead is some tens kilobytes worst case. Tested on x86, no 
regressions. I think this version of the patch is OK to merge, besides 
some TODO comments (I'd appreciate opinions on them) and the following 
maybe:


IMHO the new obstack_{mark,release} functions are the ones that will be 
harder to apply, because they make gcc's obstacks even more different 
than libc's. I sent the patch to libc-alpha but the feedback I got was 
that I should first make the two obstack versions (gcc,libc) identical, 
and then try to push changes. I've noted the primary differences and plan 
on tackling this, but it's not as trivial as it seems.


So if it's not OK, where could the new obstack_{mark,release} go?


Thanks,
Dimitris
=== modified file 'include/libiberty.h'
--- include/libiberty.h 2011-09-28 19:04:30 +
+++ include/libiberty.h 2012-07-07 16:04:01 +
@@ -361,12 +361,19 @@ extern unsigned int xcrc32 (const unsign
 #define XDUPVAR(T, P, S1, S2)  ((T *) xmemdup ((P), (S1), (S2)))
 #define XRESIZEVAR(T, P, S)((T *) xrealloc ((P), (S)))
 
-/* Type-safe obstack allocator.  */
+/* Type-safe obstack allocator. You must first initialize the obstack with
+   obstack_init() or _obstack_begin(). */
 
 #define XOBNEW(O, T)   ((T *) obstack_alloc ((O), sizeof (T)))
 #define XOBNEWVEC(O, T, N) ((T *) obstack_alloc ((O), sizeof (T) * (N)))
 #define XOBNEWVAR(O, T, S) ((T *) obstack_alloc ((O), (S)))
-#define XOBFINISH(O, T) ((T) obstack_finish ((O)))
+#define XOBDELETE(O, T, P) (obstack_free ((O), (P)))
+
+#define XOBGROW(O, T, D)   obstack_grow ((O), (D), sizeof (T))
+#define XOBGROWVEC(O, T, D, N) obstack_grow ((O), (D), sizeof (T) * (N))
+#define XOBSHRINK(O, T)obstack_blank ((O), -1 * sizeof (T))
+#define XOBSHRINKVEC(O, T, N)  obstack_blank ((O), -1 * sizeof (T) * (N))
+#define XOBFINISH(O, PT)   ((PT) obstack_finish ((O)))
 
 /* hex character manipulation routines */
 

=== modified file 'libcpp/init.c'
--- libcpp/init.c   2012-04-30 11:43:43 +
+++ libcpp/init.c   2012-07-07 16:04:01 +
@@ -241,10 +241,20 @@ cpp_create_reader (enum c_lang lang, has
   /* The expression parser stack.  */
   _cpp_expand_op_stack (pfile);
 
+#define obstack_chunk_alloc ((void *(*) (long)) xmalloc)
+#define obstack_chunk_free  ((void (*) (void *)) free)
+
   /* Initialize the buffer obstack.  */
-  _obstack_begin (&pfile->buffer_ob, 0, 0,
- (void *(*) (long)) xmalloc,
- (void (*) (void *)) free);
+  obstack_init(&pfile->buffer_ob);
+
+  /* Initialize the macro obstacks. */
+  obstack_init (&pfile->exp_ob);
+  if (CPP_OPTION (pfile, track_macro_expansion))
+{
+  obstack_init (&pfile->virt_locs_ob);
+  obstack_init (&pfile->arg_locs_ob);
+  obstack_init (&pfile->exp_locs_ob);
+}
 
   _cpp_init_files (pfile);
 
@@ -253,6 +263,9 @@ cpp_create_reader (enum c_lang lang, has
   return pfile;
 }
 
+#undef obstack_chunk_alloc
+#undef obstack_chunk_free
+
 /* Set the line_table entry in PFILE.  This is called after reading a
PCH file, as the old line_table will be incorrect.  */
 void
@@ -289,6 +302,14 @@ cpp_destroy (cpp_reader *pfile)
 deps_free (pfile->deps);
   obstack_free (&pfile->buffer_ob, 0);
 
+  obstack_free (&pfile->exp_ob, 0);
+  if (CPP_OPTION (pfile, track_macro_expansion))
+{
+  obstack_free (&pfile->virt_locs_ob, 0);
+  obstack_free (&pfile->arg_locs_ob, 0);
+  obstack_free (&pfile->exp_locs_ob, 0);
+}
+
   _cpp_destroy_hashtable (pfile);
   _cpp_cleanup_files (pfile);
   _cpp_destroy_iconv (pfile);

=== modified file 'libcpp/internal.h'
--- libcpp/internal.h   2012-05-29 09:36:29 +
+++ libcpp/internal.h   2012-07-07 17:18:53 +
@@ -555,6 +555,13 @@ struct cpp_reader
   /* If non-null, the lexer will use this location for the next token
  instead of getting a location from the linemap.  */
   source_location *forced_token_location_p;
+
+  /* Obstacks used to speed up macro expansion and virt_locs tracking. */
+  struct obstack exp_ob;   /* for expanding macro arguments */
+  /* The rest are used only when -ftrack-macro-expansion */
+  struct obstack exp_locs_ob;  /* virt_locs of expanded macro arguments */
+  struct obstack arg_locs_ob;  /* virt_locs of macro arguments */
+  struct obstack virt_locs_ob; /* virt locs for all other macros */
 };
 
 /* Character classes.  Based on the more primitive macros in safe-ctype.h.

=== modified file 'libcpp/macro.c'
--- libcpp/macro.c  2012-05-29 14:53:50 +
+++ libcpp/macro.c  2012-07-07 18:08:44 +
@@ -24,10 +24,20 @@ along with this program; see the file CO
  You are forbidden to forbid anyone else to use, share and improve
  what you give them