Emit more REG_EQUIV notes for function args (PR42235)

Emit more REG_EQUIV notes for function args (PR42235)

[Bernd Schmidt]

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]

When moving arguments into pseudos, we are being very careful not to
emit any instructions that could possibly clobber other argument
registers.  Currently, we generate unnecessarily complicated sequences
of code for simple zero or sign extensions.

With this patch, we check can_extend_p and the necessary predicates to
see if an extend insn is available for the conversion we have to do.  If
so, we emit the insn directly, and create a REG_EQUIV note of the form
(sign_extend (mem)).  Reload can't really do anything with these yet,
but there's an optimization in the register allocator to move argument
loads directly before their use if there's only one use.  On Thumb-2
this happens already, we seem to generate better code than before.
Unfortunately Thumb-1, which the PR is about, has some other problems
which I'll try to fix later.

Bootstrapped and regression tested on i686-linux.  Also regression
tested on arm-linux, with my three usual sets of options.  Ok?


Bernd

[-- Attachment #2: more-equiv-notes.diff --]
[-- Type: text/plain, Size: 3323 bytes --]

	PR target/42235
	* function.c (assign_parm_setup_reg): When an optab for extending
	exists, emit the insn directly and create a REG_EQUIV note.

Index: function.c
===================================================================
--- function.c	(revision 162146)
+++ function.c	(working copy)
@@ -2861,10 +2861,12 @@ static void
 assign_parm_setup_reg (struct assign_parm_data_all *all, tree parm,
 		       struct assign_parm_data_one *data)
 {
-  rtx parmreg;
+  rtx parmreg, validated_mem;
+  rtx equiv_stack_parm;
   enum machine_mode promoted_nominal_mode;
   int unsignedp = TYPE_UNSIGNED (TREE_TYPE (parm));
   bool did_conversion = false;
+  bool need_conversion, moved;
 
   /* Store the parm in a pseudoregister during the function, but we may
      need to do it in a wider mode.  Using 2 here makes the result
@@ -2891,10 +2893,46 @@ assign_parm_setup_reg (struct assign_par
 
   assign_parm_remove_parallels (data);
 
+  equiv_stack_parm = data->stack_parm;
+  validated_mem = validize_mem (data->entry_parm);
+
+  need_conversion = (data->nominal_mode != data->passed_mode
+		     || promoted_nominal_mode != data->promoted_mode);
+  moved = false;
+
   /* Copy the value into the register, thus bridging between
      assign_parm_find_data_types and expand_expr_real_1.  */
-  if (data->nominal_mode != data->passed_mode
-      || promoted_nominal_mode != data->promoted_mode)
+  if (need_conversion)
+    {
+      enum insn_code icode;
+      rtx op0, op1;
+
+      icode = can_extend_p (promoted_nominal_mode, data->passed_mode,
+			    unsignedp);
+
+      op0 = parmreg;
+      op1 = validated_mem;
+      if (icode != CODE_FOR_nothing
+	  && insn_data[icode].operand[0].predicate (op0, promoted_nominal_mode)
+	  && insn_data[icode].operand[1].predicate (op1, data->passed_mode))
+	{
+	  enum rtx_code code = unsignedp ? ZERO_EXTEND : SIGN_EXTEND;
+	  rtx insn;
+
+	  insn = gen_extend_insn (op0, op1, promoted_nominal_mode,
+				  data->passed_mode, unsignedp);
+	  emit_insn (insn);
+
+	  equiv_stack_parm = gen_rtx_fmt_e (code, GET_MODE (parmreg),
+					    equiv_stack_parm);
+	  moved = true;
+	}
+    }
+
+  if (moved)
+    /* Nothing to do.  */
+    ;
+  else if (need_conversion)
     {
       int save_tree_used;
 
@@ -2919,7 +2957,7 @@ assign_parm_setup_reg (struct assign_par
 
       rtx tempreg = gen_reg_rtx (GET_MODE (data->entry_parm));
 
-      emit_move_insn (tempreg, validize_mem (data->entry_parm));
+      emit_move_insn (tempreg, validated_mem);
 
       push_to_sequence2 (all->first_conversion_insn, all->last_conversion_insn);
       tempreg = convert_to_mode (data->nominal_mode, tempreg, unsignedp);
@@ -2949,7 +2987,7 @@ assign_parm_setup_reg (struct assign_par
       did_conversion = true;
     }
   else
-    emit_move_insn (parmreg, validize_mem (data->entry_parm));
+    emit_move_insn (parmreg, validated_mem);
 
   /* If we were passed a pointer but the actual value can safely live
      in a register, put it in one.  */
@@ -3034,7 +3072,7 @@ assign_parm_setup_reg (struct assign_par
 	}
       else if ((set = single_set (linsn)) != 0
 	       && SET_DEST (set) == parmreg)
-	set_unique_reg_note (linsn, REG_EQUIV, data->stack_parm);
+	set_unique_reg_note (linsn, REG_EQUIV, equiv_stack_parm);
     }
 
   /* For pointer data type, suggest pointer register.  */

Re: Emit more REG_EQUIV notes for function args (PR42235)

[Jeff Law]

On 07/14/10 05:14, Bernd Schmidt wrote:
> When moving arguments into pseudos, we are being very careful not to
> emit any instructions that could possibly clobber other argument
> registers.  Currently, we generate unnecessarily complicated sequences
> of code for simple zero or sign extensions.
>
> With this patch, we check can_extend_p and the necessary predicates to
> see if an extend insn is available for the conversion we have to do.
Right, but what guarantee do we have that the conversion insn doesn't 
clobber a function argument register?   ISTM that to be safe you 
actually have to scan the insns created by gen_extend_insn to ensure 
they don't clobber something important.

I'm not an expert on what ports do these days, but I did work on a port 
(mn10200) where conversion "insns" where implemented as special function 
calls under the hood.  I don't recall if we allowed those special 
function calls to have visible side effects, but if they did, they'd 
show up as clobbers/uses attached to the normal conversion insn.    Of 
course the mn102 is dead, but I think it's method for implementing 
conversions was valid and if another port were to do something similar 
it would likely not interact well with your change.


>   If
> so, we emit the insn directly, and create a REG_EQUIV note of the form
> (sign_extend (mem)).
Creating more REG_EQUIVs seems like a good idea to me.



>    Reload can't really do anything with these yet,
> but there's an optimization in the register allocator to move argument
> loads directly before their use if there's only one use.  On Thumb-2
> this happens already, we seem to generate better code than before.
> Unfortunately Thumb-1, which the PR is about, has some other problems
> which I'll try to fix later.
>    
In theory, given the REG_EQUIV note we ought to get an entry in 
reg_equiv_mem, which the code I'm working on knows it can use instead of 
shoving the pseudo into a stack slot.  Effectively, my code will 
rematerialize the argument from the equivalent memory location 
regardless of the number of uses.


Jeff

Re: Emit more REG_EQUIV notes for function args (PR42235)

[Bernd Schmidt]

On 07/14/2010 08:54 PM, Jeff Law wrote:
> On 07/14/10 05:14, Bernd Schmidt wrote:
>> When moving arguments into pseudos, we are being very careful not to
>> emit any instructions that could possibly clobber other argument
>> registers.  Currently, we generate unnecessarily complicated sequences
>> of code for simple zero or sign extensions.
>>
>> With this patch, we check can_extend_p and the necessary predicates to
>> see if an extend insn is available for the conversion we have to do.
> Right, but what guarantee do we have that the conversion insn doesn't
> clobber a function argument register?   ISTM that to be safe you
> actually have to scan the insns created by gen_extend_insn to ensure
> they don't clobber something important.
> 
> I'm not an expert on what ports do these days, but I did work on a port
> (mn10200) where conversion "insns" where implemented as special function
> calls under the hood.  I don't recall if we allowed those special
> function calls to have visible side effects, but if they did, they'd
> show up as clobbers/uses attached to the normal conversion insn.    Of
> course the mn102 is dead, but I think it's method for implementing
> conversions was valid and if another port were to do something similar
> it would likely not interact well with your change.

Hmm, ok.  That's awful, but I kind of expected someone would say that.
Did this really happen for integer zero/sign extend, or only for
floating point stuff?

If necessary I can try to test for a single insn with single_set and
push it to the sequence otherwise.


Bernd

Re: Emit more REG_EQUIV notes for function args (PR42235)

[Jeff Law]

On 07/14/10 15:30, Bernd Schmidt wrote:
> On 07/14/2010 08:54 PM, Jeff Law wrote:
>    
>> On 07/14/10 05:14, Bernd Schmidt wrote:
>>      
>>> When moving arguments into pseudos, we are being very careful not to
>>> emit any instructions that could possibly clobber other argument
>>> registers.  Currently, we generate unnecessarily complicated sequences
>>> of code for simple zero or sign extensions.
>>>
>>> With this patch, we check can_extend_p and the necessary predicates to
>>> see if an extend insn is available for the conversion we have to do.
>>>        
>> Right, but what guarantee do we have that the conversion insn doesn't
>> clobber a function argument register?   ISTM that to be safe you
>> actually have to scan the insns created by gen_extend_insn to ensure
>> they don't clobber something important.
>>
>> I'm not an expert on what ports do these days, but I did work on a port
>> (mn10200) where conversion "insns" where implemented as special function
>> calls under the hood.  I don't recall if we allowed those special
>> function calls to have visible side effects, but if they did, they'd
>> show up as clobbers/uses attached to the normal conversion insn.    Of
>> course the mn102 is dead, but I think it's method for implementing
>> conversions was valid and if another port were to do something similar
>> it would likely not interact well with your change.
>>      
> Hmm, ok.  That's awful, but I kind of expected someone would say that.
> Did this really happen for integer zero/sign extend, or only for
> floating point stuff?
>    
It was all the PSImode crap.

> If necessary I can try to test for a single insn with single_set and
> push it to the sequence otherwise.
>    
For the mn103, the conversions were single insns...

Ultimately,  I think you have to peek at the insn(s) and see what 
registers they set/clobber.

jeff

Re: Emit more REG_EQUIV notes for function args (PR42235)

[Bernd Schmidt]

[-- Attachment #1: Type: text/plain, Size: 439 bytes --]

On 07/15/2010 12:28 AM, Jeff Law wrote:
> On 07/14/10 15:30, Bernd Schmidt wrote:
>> If necessary I can try to test for a single insn with single_set and
>> push it to the sequence otherwise.
>>    
> For the mn103, the conversions were single insns...
> 
> Ultimately,  I think you have to peek at the insn(s) and see what
> registers they set/clobber.

How's this?  Bootstrapped and tested on i686-linux.  ARM tests in progress.


Bernd

[-- Attachment #2: more-equiv-notes2.diff --]
[-- Type: text/plain, Size: 5435 bytes --]

	PR target/42235
	* function.c (record_hard_reg_sets): New static function.
	(assign_parm_setup_reg): If an optab for extending exists and the
	generated code clobbbers no hard regs, emit the insn directly and
	create a REG_EQUIV note.

Index: gcc/function.c
===================================================================
--- gcc.orig/function.c
+++ gcc/function.c
@@ -2854,6 +2854,21 @@ assign_parm_setup_block (struct assign_p
   SET_DECL_RTL (parm, stack_parm);
 }
 
+/* A subroutine of assign_parm_setup_reg, called through note_stores.
+   This collects sets and clobbers of hard registers in a HARD_REG_SET,
+   which is pointed to by DATA.  */
+static void
+record_hard_reg_sets (rtx x, const_rtx pat ATTRIBUTE_UNUSED, void *data)
+{
+  HARD_REG_SET *pset = (HARD_REG_SET *)data;
+  if (REG_P (x) && REGNO (x) < FIRST_PSEUDO_REGISTER)
+    {
+      int nregs = hard_regno_nregs[REGNO (x)][GET_MODE (x)];
+      while (nregs-- > 0)
+	SET_HARD_REG_BIT (*pset, REGNO (x) + nregs);
+    }
+}
+
 /* A subroutine of assign_parms.  Allocate a pseudo to hold the current
    parameter.  Get it there.  Perform all ABI specified conversions.  */
 
@@ -2861,10 +2876,12 @@ static void
 assign_parm_setup_reg (struct assign_parm_data_all *all, tree parm,
 		       struct assign_parm_data_one *data)
 {
-  rtx parmreg;
+  rtx parmreg, validated_mem;
+  rtx equiv_stack_parm;
   enum machine_mode promoted_nominal_mode;
   int unsignedp = TYPE_UNSIGNED (TREE_TYPE (parm));
   bool did_conversion = false;
+  bool need_conversion, moved;
 
   /* Store the parm in a pseudoregister during the function, but we may
      need to do it in a wider mode.  Using 2 here makes the result
@@ -2893,11 +2910,16 @@ assign_parm_setup_reg (struct assign_par
 
   /* Copy the value into the register, thus bridging between
      assign_parm_find_data_types and expand_expr_real_1.  */
-  if (data->nominal_mode != data->passed_mode
-      || promoted_nominal_mode != data->promoted_mode)
-    {
-      int save_tree_used;
 
+  equiv_stack_parm = data->stack_parm;
+  validated_mem = validize_mem (data->entry_parm);
+
+  need_conversion = (data->nominal_mode != data->passed_mode
+		     || promoted_nominal_mode != data->promoted_mode);
+  moved = false;
+
+  if (need_conversion)
+    {
       /* ENTRY_PARM has been converted to PROMOTED_MODE, its
 	 mode, by the caller.  We now have to convert it to
 	 NOMINAL_MODE, if different.  However, PARMREG may be in
@@ -2913,13 +2935,70 @@ assign_parm_setup_reg (struct assign_par
 
 	 In addition, the conversion may involve a call, which could
 	 clobber parameters which haven't been copied to pseudo
-	 registers yet.  Therefore, we must first copy the parm to
-	 a pseudo reg here, and save the conversion until after all
+	 registers yet.
+
+	 First, we try to emit an insn which performs the necessary
+	 conversion.  We verify that this insn does not clobber any
+	 hard registers.  */
+
+      enum insn_code icode;
+      rtx op0, op1;
+
+      icode = can_extend_p (promoted_nominal_mode, data->passed_mode,
+			    unsignedp);
+
+      op0 = parmreg;
+      op1 = validated_mem;
+      if (icode != CODE_FOR_nothing
+	  && insn_data[icode].operand[0].predicate (op0, promoted_nominal_mode)
+	  && insn_data[icode].operand[1].predicate (op1, data->passed_mode))
+	{
+	  enum rtx_code code = unsignedp ? ZERO_EXTEND : SIGN_EXTEND;
+	  rtx insn, insns;
+	  HARD_REG_SET hardregs;
+
+	  start_sequence ();
+	  insn = gen_extend_insn (op0, op1, promoted_nominal_mode,
+				  data->passed_mode, unsignedp);
+	  emit_insn (insn);
+	  insns = get_insns ();
+
+	  moved = true;
+	  CLEAR_HARD_REG_SET (hardregs);
+	  for (insn = insns; insn && moved; insn = NEXT_INSN (insn))
+	    {
+	      if (INSN_P (insn))
+		note_stores (PATTERN (insn), record_hard_reg_sets,
+			     &hardregs);
+	      if (!hard_reg_set_empty_p (hardregs))
+		moved = false;
+	    }
+
+	  end_sequence ();
+
+	  if (moved)
+	    {
+	      emit_insn (insns);
+	      equiv_stack_parm = gen_rtx_fmt_e (code, GET_MODE (parmreg),
+						equiv_stack_parm);
+	    }
+	}
+    }
+
+  if (moved)
+    /* Nothing to do.  */
+    ;
+  else if (need_conversion)
+    {
+      /* We did not have an insn to convert directly, or the sequence
+	 generated appeared unsafe.  We must first copy the parm to a
+	 pseudo reg, and save the conversion until after all
 	 parameters have been moved.  */
 
+      int save_tree_used;
       rtx tempreg = gen_reg_rtx (GET_MODE (data->entry_parm));
 
-      emit_move_insn (tempreg, validize_mem (data->entry_parm));
+      emit_move_insn (tempreg, validated_mem);
 
       push_to_sequence2 (all->first_conversion_insn, all->last_conversion_insn);
       tempreg = convert_to_mode (data->nominal_mode, tempreg, unsignedp);
@@ -2949,7 +3028,7 @@ assign_parm_setup_reg (struct assign_par
       did_conversion = true;
     }
   else
-    emit_move_insn (parmreg, validize_mem (data->entry_parm));
+    emit_move_insn (parmreg, validated_mem);
 
   /* If we were passed a pointer but the actual value can safely live
      in a register, put it in one.  */
@@ -3034,7 +3113,7 @@ assign_parm_setup_reg (struct assign_par
 	}
       else if ((set = single_set (linsn)) != 0
 	       && SET_DEST (set) == parmreg)
-	set_unique_reg_note (linsn, REG_EQUIV, data->stack_parm);
+	set_unique_reg_note (linsn, REG_EQUIV, equiv_stack_parm);
     }
 
   /* For pointer data type, suggest pointer register.  */

Re: Emit more REG_EQUIV notes for function args (PR42235)

[Jeff Law]

On 07/15/10 11:13, Bernd Schmidt wrote:
> On 07/15/2010 12:28 AM, Jeff Law wrote:
>    
>> On 07/14/10 15:30, Bernd Schmidt wrote:
>>      
>>> If necessary I can try to test for a single insn with single_set and
>>> push it to the sequence otherwise.
>>>
>>>        
>> For the mn103, the conversions were single insns...
>>
>> Ultimately,  I think you have to peek at the insn(s) and see what
>> registers they set/clobber.
>>      
> How's this?  Bootstrapped and tested on i686-linux.  ARM tests in progress.
>    
OK.
Jeff

Re: Emit more REG_EQUIV notes for function args (PR42235)

[Bernd Schmidt]

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

On 07/15/2010 07:13 PM, Bernd Schmidt wrote:
> On 07/15/2010 12:28 AM, Jeff Law wrote:
>> On 07/14/10 15:30, Bernd Schmidt wrote:
>>> If necessary I can try to test for a single insn with single_set and
>>> push it to the sequence otherwise.
>>>    
>> For the mn103, the conversions were single insns...
>>
>> Ultimately,  I think you have to peek at the insn(s) and see what
>> registers they set/clobber.
> 
> How's this?  Bootstrapped and tested on i686-linux.  ARM tests in progress.

This seems to have caused a bootstrap failure on hppa.  A QImode value
is passed in a SImode reg and then should get extended to DImode; we
must make sure we use a qidi extension.  The following patch does that;
I've not heard back whether it fixes the hppa bootstrap, but it seems to
work on arm-linux (one extra testsuite failure caused by an unrelated
change in the same tree).  Also bootstrapped on i686-linux.  Ok?


Bernd

[-- Attachment #2: entrymode.diff --]
[-- Type: text/plain, Size: 1376 bytes --]

	* function.c (assign_parm_setup_reg): Use nominal_mode as the
	source mode for extensions.

Index: function.c
===================================================================
--- function.c	(revision 162277)
+++ function.c	(working copy)
@@ -2940,18 +2940,18 @@ assign_parm_setup_reg (struct assign_par
 	 First, we try to emit an insn which performs the necessary
 	 conversion.  We verify that this insn does not clobber any
 	 hard registers.  */
-
+      enum machine_mode entry_mode = data->nominal_mode;
       enum insn_code icode;
       rtx op0, op1;
 
-      icode = can_extend_p (promoted_nominal_mode, data->passed_mode,
+      icode = can_extend_p (promoted_nominal_mode, entry_mode,
 			    unsignedp);
 
       op0 = parmreg;
       op1 = validated_mem;
       if (icode != CODE_FOR_nothing
 	  && insn_data[icode].operand[0].predicate (op0, promoted_nominal_mode)
-	  && insn_data[icode].operand[1].predicate (op1, data->passed_mode))
+	  && insn_data[icode].operand[1].predicate (op1, entry_mode))
 	{
 	  enum rtx_code code = unsignedp ? ZERO_EXTEND : SIGN_EXTEND;
 	  rtx insn, insns;
@@ -2959,7 +2959,7 @@ assign_parm_setup_reg (struct assign_par
 
 	  start_sequence ();
 	  insn = gen_extend_insn (op0, op1, promoted_nominal_mode,
-				  data->passed_mode, unsignedp);
+				  entry_mode, unsignedp);
 	  emit_insn (insn);
 	  insns = get_insns ();
 

Re: Emit more REG_EQUIV notes for function args (PR42235)

[Jeff Law]

On 07/19/10 03:54, Bernd Schmidt wrote:
> On 07/15/2010 07:13 PM, Bernd Schmidt wrote:
>    
>> On 07/15/2010 12:28 AM, Jeff Law wrote:
>>      
>>> On 07/14/10 15:30, Bernd Schmidt wrote:
>>>        
>>>> If necessary I can try to test for a single insn with single_set and
>>>> push it to the sequence otherwise.
>>>>
>>>>          
>>> For the mn103, the conversions were single insns...
>>>
>>> Ultimately,  I think you have to peek at the insn(s) and see what
>>> registers they set/clobber.
>>>        
>> How's this?  Bootstrapped and tested on i686-linux.  ARM tests in progress.
>>      
> This seems to have caused a bootstrap failure on hppa.  A QImode value
> is passed in a SImode reg and then should get extended to DImode; we
> must make sure we use a qidi extension.  The following patch does that;
> I've not heard back whether it fixes the hppa bootstrap, but it seems to
> work on arm-linux (one extra testsuite failure caused by an unrelated
> change in the same tree).  Also bootstrapped on i686-linux.  Ok?
>    
Assuming John confirms it fixes the PA failure.  OK.

jeff

Re: Emit more REG_EQUIV notes for function args (PR42235)

[Bernd Schmidt]

On 07/19/2010 06:51 PM, Jeff Law wrote:
> Assuming John confirms it fixes the PA failure.  OK.

Yeah, it didn't, and I think I missed a gen_lowpart in there anyway :-(
 Now trying to do something with the compilefarm PA machine, although
I'm not sure it's a 64-bit one (is it?)


Bernd

Re: Emit more REG_EQUIV notes for function args (PR42235)

[Richard Henderson]

On 07/19/2010 09:52 AM, Bernd Schmidt wrote:
> On 07/19/2010 06:51 PM, Jeff Law wrote:
>> Assuming John confirms it fixes the PA failure.  OK.
> 
> Yeah, it didn't, and I think I missed a gen_lowpart in there anyway :-(
>  Now trying to do something with the compilefarm PA machine, although
> I'm not sure it's a 64-bit one (is it?)

It's 64-bit hw running a 32-bit os, so... no, not really.


r~

Re: Emit more REG_EQUIV notes for function args (PR42235)

[Jeff Law]

On 07/19/10 10:52, Bernd Schmidt wrote:
> On 07/19/2010 06:51 PM, Jeff Law wrote:
>    
>> Assuming John confirms it fixes the PA failure.  OK.
>>      
> Yeah, it didn't, and I think I missed a gen_lowpart in there anyway :-(
>   Now trying to do something with the compilefarm PA machine, although
> I'm not sure it's a 64-bit one (is it?)
>    
No clue.  What does config.guess report?

If it reports hppa2.0w, then it's running in 64bit mode.  hppa2.0 is the 
same hardware running in 32bit mode.

My hppa2.0w machine is extremely flakey; last I tried, I couldn't get it 
to run long enough to get through stage1, so I can't be much direct help.

Jeff

Re: Emit more REG_EQUIV notes for function args (PR42235)

[John David Anglin]

> On 07/19/2010 06:51 PM, Jeff Law wrote:
> > Assuming John confirms it fixes the PA failure.  OK.
> 
> Yeah, it didn't, and I think I missed a gen_lowpart in there anyway :-(
>  Now trying to do something with the compilefarm PA machine, although
> I'm not sure it's a 64-bit one (is it?)

I never use it.  HP-UX on "current" machines supports both 32 and 64-bit.
However, generating the initial 64-bit gcc version is still a bit tricky
if it is not present.  Linux only has a 32-bit runtime.

The failure was a null pointer fault.  However, it has been passed through
multiple layers of inlined functions, and gdb isn't working well.  So,
I haven't been able to find the fault.  I think I'll retry the testsuite
to see if I can find some more simple failures.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Emit more REG_EQUIV notes for function args (PR42235)

[Bernd Schmidt]

[-- Attachment #1: Type: text/plain, Size: 199 bytes --]

Here's a different patch, which I've committed as obvious after
bootstrapping and testing i686 and x64_64-linux.  It just restricts the
previous change to situations where it's clearly safe.


Bernd

[-- Attachment #2: parm-equiv-fix.diff --]
[-- Type: text/plain, Size: 1526 bytes --]

Index: ChangeLog
===================================================================
--- ChangeLog	(revision 162390)
+++ ChangeLog	(working copy)
@@ -18,6 +18,10 @@
 	an old insn, ignore a use that occurs after store_ruid.
 	* Makefile.in (postreload.o): Update dependencies.
 
+	* function.c (record_hard_reg_sets): Restrict the previous change
+	to cases where the incoming nominal mode is the same as the
+	incoming promoted mode and everything happens in MODE_INT.
+
 2010-07-21  Jakub Jelinek  <jakub@redhat.com>
 
 	PR debug/45015
Index: function.c
===================================================================
--- function.c	(revision 162372)
+++ function.c	(working copy)
@@ -2918,7 +2918,10 @@ assign_parm_setup_reg (struct assign_par
 		     || promoted_nominal_mode != data->promoted_mode);
   moved = false;
 
-  if (need_conversion)
+  if (need_conversion
+      && GET_MODE_CLASS (data->nominal_mode) == MODE_INT
+      && data->nominal_mode == data->passed_mode
+      && data->nominal_mode == GET_MODE (data->entry_parm))
     {
       /* ENTRY_PARM has been converted to PROMOTED_MODE, its
 	 mode, by the caller.  We now have to convert it to
@@ -2979,8 +2982,9 @@ assign_parm_setup_reg (struct assign_par
 	  if (moved)
 	    {
 	      emit_insn (insns);
-	      equiv_stack_parm = gen_rtx_fmt_e (code, GET_MODE (parmreg),
-						equiv_stack_parm);
+	      if (equiv_stack_parm != NULL_RTX)
+		equiv_stack_parm = gen_rtx_fmt_e (code, GET_MODE (parmreg),
+						  equiv_stack_parm);
 	    }
 	}
     }

Re: Emit more REG_EQUIV notes for function args (PR42235)

[Bernd Schmidt]

On 07/14/2010 08:54 PM, Jeff Law wrote:
> In theory, given the REG_EQUIV note we ought to get an entry in
> reg_equiv_mem, which the code I'm working on knows it can use instead of
> shoving the pseudo into a stack slot.  Effectively, my code will
> rematerialize the argument from the equivalent memory location
> regardless of the number of uses.

Reload can do that already, I think, but it's not prepared to handle a
(zero_extend (mem)) inside a REG_EQUIV note.  That should be reasonably
trivial to add if the reg is never set other than in the initializing insn.


Bernd

Re: Emit more REG_EQUIV notes for function args (PR42235)

[Jeff Law]

On 07/14/10 15:47, Bernd Schmidt wrote:
> On 07/14/2010 08:54 PM, Jeff Law wrote:
>    
>> In theory, given the REG_EQUIV note we ought to get an entry in
>> reg_equiv_mem, which the code I'm working on knows it can use instead of
>> shoving the pseudo into a stack slot.  Effectively, my code will
>> rematerialize the argument from the equivalent memory location
>> regardless of the number of uses.
>>      
> Reload can do that already, I think, but it's not prepared to handle a
> (zero_extend (mem)) inside a REG_EQUIV note.  That should be reasonably
> trivial to add if the reg is never set other than in the initializing insn.
>    
reload does, but it's code that can be problematical.  For example, 
replacement of an unallocated pseudo with its equivalent can trigger 
secondary reloads, spills, etc.

My code creates a new pseudo/allocno for the various ranges where the 
unallocated pseudo is live then asks IRA to color those split-range 
pseudos/allocnos.  What we end up presenting to reload is cleaner; 
though often they result in the same final code.  Handling this case 
falls out nicely from the infrastructure for splitting ranges of 
unallocated pseudos without equivalent forms (it's probably a couple 
dozen lines of new code).

jeff