public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] rs6000: Fix for separate shrink-wrapping for fp (PR80860, PR80843)
@ 2017-05-23 11:07 Segher Boessenkool
  2017-05-24 14:54 ` Segher Boessenkool
  0 siblings, 1 reply; 2+ messages in thread
From: Segher Boessenkool @ 2017-05-23 11:07 UTC (permalink / raw)
  To: gcc-patches; +Cc: dje.gcc, Segher Boessenkool

After my r248256, rs6000_components_for_bb allocates an sbitmap of size
only 32 while it can use up to 64.  This patch fixes it.  It moves the
n_components variable into the machine_function struct so that other
hooks can use it.

Tested on powerpc64-linux {-m32,-m64}.  Will also test on AIX before
committing.

I cannot reproduce PR80843 (I have trouble building a 32-bit hosted
compiler), but I suspect it is the same problem.


Segher


2017-05-23  Segher Boessenkool  <segher@kernel.crashing.org>

	PR bootstrap/80860
	PR bootstrap/80843
	* config/rs6000/rs6000.c (struct machine_function): Add new field
	n_components.
	(rs6000_get_separate_components): Init that field, use it.
	(rs6000_components_for_bb): Use the field.

---
 gcc/config/rs6000/rs6000.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index a017afc..f45bb7a 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -154,6 +154,8 @@ typedef struct GTY(()) machine_function
   bool split_stack_argp_used;
   /* Flag if r2 setup is needed with ELFv2 ABI.  */
   bool r2_setup_needed;
+  /* The number of components we use for separate shrink-wrapping.  */
+  int n_components;
   /* The components already handled by separate shrink-wrapping, which should
      not be considered by the prologue and epilogue.  */
   bool gpr_is_wrapped_separately[32];
@@ -29368,9 +29370,9 @@ rs6000_get_separate_components (void)
      Components 13..31 are the save/restore of GPR13..GPR31.
      Components 46..63 are the save/restore of FPR14..FPR31.  */
 
-  int n_components = 64;
+  cfun->machine->n_components = 64;
 
-  sbitmap components = sbitmap_alloc (n_components);
+  sbitmap components = sbitmap_alloc (cfun->machine->n_components);
   bitmap_clear (components);
 
   int reg_size = TARGET_32BIT ? 4 : 8;
@@ -29462,7 +29464,7 @@ rs6000_components_for_bb (basic_block bb)
   bitmap gen = &DF_LIVE_BB_INFO (bb)->gen;
   bitmap kill = &DF_LIVE_BB_INFO (bb)->kill;
 
-  sbitmap components = sbitmap_alloc (32);
+  sbitmap components = sbitmap_alloc (cfun->machine->n_components);
   bitmap_clear (components);
 
   /* A register is used in a bb if it is in the IN, GEN, or KILL sets.  */
-- 
1.9.3

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH] rs6000: Fix for separate shrink-wrapping for fp (PR80860, PR80843)
  2017-05-23 11:07 [PATCH] rs6000: Fix for separate shrink-wrapping for fp (PR80860, PR80843) Segher Boessenkool
@ 2017-05-24 14:54 ` Segher Boessenkool
  0 siblings, 0 replies; 2+ messages in thread
From: Segher Boessenkool @ 2017-05-24 14:54 UTC (permalink / raw)
  To: gcc-patches; +Cc: dje.gcc

On Tue, May 23, 2017 at 11:07:07AM +0000, Segher Boessenkool wrote:
> After my r248256, rs6000_components_for_bb allocates an sbitmap of size
> only 32 while it can use up to 64.  This patch fixes it.  It moves the
> n_components variable into the machine_function struct so that other
> hooks can use it.
> 
> Tested on powerpc64-linux {-m32,-m64}.  Will also test on AIX before
> committing.

This fixed the AIX problem (PR80860).  I have committed this now.


Segher

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2017-05-24 14:37 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-23 11:07 [PATCH] rs6000: Fix for separate shrink-wrapping for fp (PR80860, PR80843) Segher Boessenkool
2017-05-24 14:54 ` Segher Boessenkool

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).