| Message ID | 877hl7rncg.fsf@firetop.home |
|---|---|
| State | New |
| Headers | show |
On 07/07/2010 02:30 PM, Richard Sandiford wrote: > + /* Nonzero for each mode that supports (set (reg) (reg)). > + This is trivially true for integer and floating point values. > + It may or may not be true for condition codes. */ > + int x_can_copy[(int) NUM_MACHINE_MODES]; ... > -static char can_copy[(int) NUM_MACHINE_MODES]; Type changed. For the most part I think *most* of the "char" variables that you're moving should really be "bool". However, I think that should be done in separate changes. r~
Richard Henderson <rth@redhat.com> writes: > On 07/07/2010 02:30 PM, Richard Sandiford wrote: >> + /* Nonzero for each mode that supports (set (reg) (reg)). >> + This is trivially true for integer and floating point values. >> + It may or may not be true for condition codes. */ >> + int x_can_copy[(int) NUM_MACHINE_MODES]; > ... >> -static char can_copy[(int) NUM_MACHINE_MODES]; > > Type changed. Gah, good catch. That was careless. > For the most part I think *most* of the "char" variables that > you're moving should really be "bool". However, I think that > should be done in separate changes. Yeah, agreed that bool would be nicer. I vaguely recall a discussion about whether that was a good idea though, given that hosts like Darwin define bool to be wider than char. More fool them, I suppose. Richard
On Jul 10, 2010, at 6:59 AM, Richard Sandiford wrote: >> For the most part I think *most* of the "char" variables that >> you're moving should really be "bool". However, I think that >> should be done in separate changes. > > Yeah, agreed that bool would be nicer. I vaguely recall a discussion > about whether that was a good idea though, given that hosts like Darwin > define bool to be wider than char. More fool them, I suppose. :-) Hey, for -fwhole-program, is there a narrowing pass that can change 4 byte variables into 1 byte variables? I'd not object to using the arguably better bool for these things. bool is only 4 bytes on ppc, not on any of the x86 targets.
On Jul 11, 2010, at 12:54 PM, Mike Stump <mikestump@comcast.net> wrote: > On Jul 10, 2010, at 6:59 AM, Richard Sandiford wrote: >>> For the most part I think *most* of the "char" variables that >>> you're moving should really be "bool". However, I think that >>> should be done in separate changes. >> >> Yeah, agreed that bool would be nicer. I vaguely recall a discussion >> about whether that was a good idea though, given that hosts like >> Darwin >> define bool to be wider than char. More fool them, I suppose. > > :-) Hey, for -fwhole-program, is there a narrowing pass that can > change 4 byte variables into 1 byte variables? I'd not object to > using the arguably better bool for these things. bool is only 4 > bytes on ppc, not on any of the x86 targets. Actually bool is only 4 bytes on ppc Darwin. No other host or target. From what I remember this was done not to break the abi. I would say let's not worry about ppc Darwin as a host any more as there are no new versions of the os being released.
On 11 Jul 2010, at 21:03, Andrew Pinski wrote: > > On Jul 11, 2010, at 12:54 PM, Mike Stump <mikestump@comcast.net> > wrote: > >> On Jul 10, 2010, at 6:59 AM, Richard Sandiford wrote: >>>> For the most part I think *most* of the "char" variables that >>>> you're moving should really be "bool". However, I think that >>>> should be done in separate changes. >>> >>> Yeah, agreed that bool would be nicer. I vaguely recall a >>> discussion >>> about whether that was a good idea though, given that hosts like >>> Darwin >>> define bool to be wider than char. More fool them, I suppose. >> >> :-) Hey, for -fwhole-program, is there a narrowing pass that can >> change 4 byte variables into 1 byte variables? I'd not object to >> using the arguably better bool for these things. bool is only 4 >> bytes on ppc, not on any of the x86 targets. > > > Actually bool is only 4 bytes on ppc Darwin. No other host or > target. From what I remember this was done not to break the abi. I > would say let's not worry about ppc Darwin as a host any more as > there are no new versions of the os being released. Fair enough that there should be little if any priority for future development. Conversely FSF gcc is the *only* compiler with any modern development for the remaining useful ppc systems (one of which I'm typing this on). Despite the ideals of Hacking Heaven .. most of us cannot afford to toss away good quality working hardware that is < 5 years old :-) Please don't break it unless it's actually necessary. (and yes, I do have other systems, including an 8-core intel system, but this quad g5 _is_ still useful). Iain
On Jul 11, 2010, at 1:15 PM, IainS <developer@sandoe-acoustics.co.uk> wrote: > > On 11 Jul 2010, at 21:03, Andrew Pinski wrote: >> >> On Jul 11, 2010, at 12:54 PM, Mike Stump <mikestump@comcast.net> >> wrote: >> >>> On Jul 10, 2010, at 6:59 AM, Richard Sandiford wrote: >>>>> For the most part I think *most* of the "char" variables that >>>>> you're moving should really be "bool". However, I think that >>>>> should be done in separate changes. >>>> >>>> Yeah, agreed that bool would be nicer. I vaguely recall a >>>> discussion >>>> about whether that was a good idea though, given that hosts like >>>> Darwin >>>> define bool to be wider than char. More fool them, I suppose. >>> >>> :-) Hey, for -fwhole-program, is there a narrowing pass that can >>> change 4 byte variables into 1 byte variables? I'd not object to >>> using the arguably better bool for these things. bool is only 4 >>> bytes on ppc, not on any of the x86 targets. >> >> >> Actually bool is only 4 bytes on ppc Darwin. No other host or >> target. From what I remember this was done not to break the abi. I >> would say let's not worry about ppc Darwin as a host any more as >> there are no new versions of the os being released. > > Fair enough that there should be little if any priority for future > development. > > Conversely FSF gcc is the *only* compiler with any modern > development for the remaining useful ppc systems (one of which I'm > typing this on). > Despite the ideals of Hacking Heaven .. most of us cannot afford to > toss away good quality working hardware that is < 5 years old :-) > Please don't break it unless it's actually necessary. > The use of bool is not going to break anything; just might slow down the compiler slightly. The data cache might be fuller. Don't be scared away because the compiler slows down for a little bit while things are in flux to speed up in the long term. > (and yes, I do have other systems, including an 8-core intel system, > but this quad g5 _is_ still useful). > Iain >
On 11 Jul 2010, at 21:24, Andrew Pinski wrote: > > > On Jul 11, 2010, at 1:15 PM, IainS <developer@sandoe- > acoustics.co.uk> wrote: > >> >> On 11 Jul 2010, at 21:03, Andrew Pinski wrote: >>> >>> On Jul 11, 2010, at 12:54 PM, Mike Stump <mikestump@comcast.net> >>> wrote: >>> >>>> On Jul 10, 2010, at 6:59 AM, Richard Sandiford wrote: >>>>>> For the most part I think *most* of the "char" variables that >>>>>> you're moving should really be "bool". However, I think that >>>>>> should be done in separate changes. >>>>> >>>>> Yeah, agreed that bool would be nicer. I vaguely recall a >>>>> discussion >>>>> about whether that was a good idea though, given that hosts like >>>>> Darwin >>>>> define bool to be wider than char. More fool them, I suppose. >>>> >>>> :-) Hey, for -fwhole-program, is there a narrowing pass that can >>>> change 4 byte variables into 1 byte variables? I'd not object to >>>> using the arguably better bool for these things. bool is only 4 >>>> bytes on ppc, not on any of the x86 targets. >>> >>> >>> Actually bool is only 4 bytes on ppc Darwin. No other host or >>> target. From what I remember this was done not to break the abi. I >>> would say let's not worry about ppc Darwin as a host any more as >>> there are no new versions of the os being released. >> >> Fair enough that there should be little if any priority for future >> development. >> >> Conversely FSF gcc is the *only* compiler with any modern >> development for the remaining useful ppc systems (one of which I'm >> typing this on). >> Despite the ideals of Hacking Heaven .. most of us cannot afford to >> toss away good quality working hardware that is < 5 years old :-) >> Please don't break it unless it's actually necessary. >> > > The use of bool is not going to break anything; just might slow down > the compiler slightly. The data cache might be fuller. Don't be > scared away because the compiler slows down for a little bit while > things are in flux to speed up in the long term. well, I'm not worried about temporary slowing down (or even, if absolutely necessary, a long-term penalty in bools for the platform). ... I was more concerned by the "let's just drop support for the platform" idea ;-) Now I see that's not what you meant... Iain.
Index: gcc/Makefile.in =================================================================== --- gcc/Makefile.in 2010-07-07 22:21:40.000000000 +0100 +++ gcc/Makefile.in 2010-07-07 22:29:12.000000000 +0100 @@ -3094,7 +3094,7 @@ gcse.o : gcse.c $(CONFIG_H) $(SYSTEM_H) $(RECOG_H) $(EXPR_H) $(BASIC_BLOCK_H) $(FUNCTION_H) output.h $(TOPLEV_H) \ $(TM_P_H) $(PARAMS_H) cselib.h $(EXCEPT_H) gt-gcse.h $(TREE_H) $(TIMEVAR_H) \ intl.h $(OBSTACK_H) $(TREE_PASS_H) $(DF_H) $(DBGCNT_H) $(TARGET_H) \ - $(DF_H) + $(DF_H) gcse.h store-motion.o : store-motion.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(RTL_H) \ $(REGS_H) hard-reg-set.h $(FLAGS_H) insn-config.h $(GGC_H) \ $(RECOG_H) $(EXPR_H) $(BASIC_BLOCK_H) $(FUNCTION_H) output.h $(TOPLEV_H) \ @@ -3479,7 +3479,7 @@ lower-subreg.o : lower-subreg.c $(CONFIG target-globals.o : target-globals.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \ $(TM_H) insn-config.h $(MACHMODE_H) $(GGC_H) $(TOPLEV_H) target-globals.h \ $(FLAGS_H) $(REGS_H) $(RTL_H) reload.h expmed.h $(EXPR_H) $(OPTABS_H) \ - $(LIBFUNCS_H) $(CFGLOOP_H) $(IRA_INT_H) builtins.h + $(LIBFUNCS_H) $(CFGLOOP_H) $(IRA_INT_H) builtins.h gcse.h $(out_object_file): $(out_file) $(CONFIG_H) coretypes.h $(TM_H) $(TREE_H) \ $(RTL_H) $(REGS_H) hard-reg-set.h insn-config.h conditions.h \ Index: gcc/gcse.h =================================================================== --- /dev/null 2010-07-07 22:25:18.139280603 +0100 +++ gcc/gcse.h 2010-07-07 22:29:12.000000000 +0100 @@ -0,0 +1,43 @@ +/* Global common subexpression elimination/Partial redundancy elimination + and global constant/copy propagation for GNU compiler. + Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, + 2006, 2007, 2008, 2009, 2010 Free Software Foundation, Inc. + +This file is part of GCC. + +GCC is free software; you can redistribute it and/or modify it under +the terms of the GNU General Public License as published by the Free +Software Foundation; either version 3, or (at your option) any later +version. + +GCC is distributed in the hope that it will be useful, but WITHOUT ANY +WARRANTY; without even the implied warranty of MERCHANTABILITY or +FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +for more details. + +You should have received a copy of the GNU General Public License +along with GCC; see the file COPYING3. If not see +<http://www.gnu.org/licenses/>. */ + +#ifndef GCC_GCSE_H +#define GCC_GCSE_H + +/* Target-dependent globals. */ +struct target_gcse { + /* Nonzero for each mode that supports (set (reg) (reg)). + This is trivially true for integer and floating point values. + It may or may not be true for condition codes. */ + int x_can_copy[(int) NUM_MACHINE_MODES]; + + /* True if the previous field has been initialized. */ + bool x_can_copy_init_p; +}; + +extern GTY(()) struct target_gcse default_target_gcse; +#if SWITCHABLE_TARGET +extern struct target_gcse *this_target_gcse; +#else +#define this_target_gcse (&default_target_gcse) +#endif + +#endif Index: gcc/gcse.c =================================================================== --- gcc/gcse.c 2010-07-04 22:48:28.000000000 +0100 +++ gcc/gcse.c 2010-07-07 22:29:12.000000000 +0100 @@ -169,6 +169,7 @@ Software Foundation; either version 3, o #include "df.h" #include "dbgcnt.h" #include "target.h" +#include "gcse.h" /* We support GCSE via Partial Redundancy Elimination. PRE optimizations are a superset of those done by classic GCSE. @@ -262,6 +263,11 @@ Software Foundation; either version 3, o /* GCSE global vars. */ +struct target_gcse default_target_gcse; +#if SWITCHABLE_TARGET +struct target_gcse *this_target_gcse = &default_target_gcse; +#endif + /* Set to non-zero if CSE should run after all GCSE optimizations are done. */ int flag_rerun_cse_after_global_opts; @@ -538,10 +544,10 @@ #define GOBNEWVAR(T, S) ((T *) gcse_all /* Misc. utilities. */ -/* Nonzero for each mode that supports (set (reg) (reg)). - This is trivially true for integer and floating point values. - It may or may not be true for condition codes. */ -static char can_copy[(int) NUM_MACHINE_MODES]; +#define can_copy \ + (this_target_gcse->x_can_copy) +#define can_copy_init_p \ + (this_target_gcse->x_can_copy_init_p) /* Compute which modes support reg/reg copy operations. */ @@ -578,8 +584,6 @@ compute_can_copy (void) bool can_copy_p (enum machine_mode mode) { - static bool can_copy_init_p = false; - if (! can_copy_init_p) { compute_can_copy (); Index: gcc/target-globals.h =================================================================== --- gcc/target-globals.h 2010-07-07 22:21:40.000000000 +0100 +++ gcc/target-globals.h 2010-07-07 22:29:12.000000000 +0100 @@ -33,6 +33,7 @@ #define TARGET_GLOBALS_H 1 extern struct target_ira *this_target_ira; extern struct target_ira_int *this_target_ira_int; extern struct target_builtins *this_target_builtins; +extern struct target_gcse *this_target_gcse; struct GTY(()) target_globals { struct target_flag_state *GTY((skip)) flag_state; @@ -47,6 +48,7 @@ struct GTY(()) target_globals { struct target_ira *GTY((skip)) ira; struct target_ira_int *GTY((skip)) ira_int; struct target_builtins *GTY((skip)) builtins; + struct target_gcse *GTY((skip)) gcse; }; extern struct target_globals default_target_globals; @@ -68,6 +70,7 @@ restore_target_globals (struct target_gl this_target_ira = g->ira; this_target_ira_int = g->ira_int; this_target_builtins = g->builtins; + this_target_gcse = g->gcse; } #endif Index: gcc/target-globals.c =================================================================== --- gcc/target-globals.c 2010-07-07 22:21:40.000000000 +0100 +++ gcc/target-globals.c 2010-07-07 22:29:12.000000000 +0100 @@ -38,6 +38,7 @@ Software Foundation; either version 3, o #include "cfgloop.h" #include "ira-int.h" #include "builtins.h" +#include "gcse.h" #if SWITCHABLE_TARGET struct target_globals default_target_globals = { @@ -52,7 +53,8 @@ struct target_globals default_target_glo &default_target_cfgloop, &default_target_ira, &default_target_ira_int, - &default_target_builtins + &default_target_builtins, + &default_target_gcse }; struct target_globals * @@ -73,6 +75,7 @@ save_target_globals (void) g->ira = XCNEW (struct target_ira); g->ira_int = XCNEW (struct target_ira_int); g->builtins = XCNEW (struct target_builtins); + g->gcse = XCNEW (struct target_gcse); restore_target_globals (g); target_reinit (); return g;