Patchwork Emit more REG_EQUIV notes for function args (PR42235)

login
register
mail settings
Submitter Bernd Schmidt
Date July 19, 2010, 9:54 a.m.
Message ID <4C4420F2.5010807@codesourcery.com>
Download mbox | patch
Permalink /patch/59185/
State New
Headers show

Comments

Bernd Schmidt - July 19, 2010, 9:54 a.m.
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
* function.c (assign_parm_setup_reg): Use nominal_mode as the
	source mode for extensions.
Jeff Law - July 19, 2010, 4:51 p.m.
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
Bernd Schmidt - July 19, 2010, 4:52 p.m.
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
Richard Henderson - July 19, 2010, 4:59 p.m.
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~
Jeff Law - July 19, 2010, 5:09 p.m.
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

Patch

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 ();