Patchwork [24/27] Put gcse's can_copy hash into target structures

login
register
mail settings
Submitter Richard Sandiford
Date July 7, 2010, 9:30 p.m.
Message ID <877hl7rncg.fsf@firetop.home>
Download mbox | patch
Permalink /patch/58191/
State New
Headers show

Comments

Richard Sandiford - July 7, 2010, 9:30 p.m.
GCSE caches whether it it can copy values in a particular mode.
This property is target-dependent.

Richard


gcc/
	* Makefile.in (gcse.o, target-globals.o): Depend on gcse.h..
	* gcse.h: New file.
	* gcse.c: Include gcse.h.
	(default_target_gcse): New variable.
	(this_target_gcse): New conditional variable.
	(can_copy): Redefine as a macro.
	(can_copy_init_p): New macro.
	(can_copy_p): Remove can_copy_init_p.
	* target-globals.h (this_target_gcse): Declare.
	(target_globals): Add a gcse field.
	(restore_target_globals): Copy the gcse field to
	this_target_gcse.
	* target-globals.c: Include gcse.h.
	(default_target_globals): Initialize the gcse field.
	(save_target_globals): Likewise.
Richard Henderson - July 7, 2010, 10:17 p.m.
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 Sandiford - July 10, 2010, 1:59 p.m.
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
Mike Stump - July 11, 2010, 7:54 p.m.
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.
Andrew Pinski - July 11, 2010, 8:03 p.m.
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.
IainS - July 11, 2010, 8:15 p.m.
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
Andrew Pinski - July 11, 2010, 8:24 p.m.
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
>
IainS - July 11, 2010, 8:29 p.m.
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.

Patch

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;