RE: Reload problem: asm operand requires impossible reload

["Bingfeng Mei" <bmei at broadcom dot com>]

Ian,
I would like to come back to this issue after being away for two weeks (if you still
can remember the problem :-)). I tried to track the problem with other target (ARM),
and it doesn't show up. After some investigation, I found the pseudo register
is accepted by constrain_operands function even when strict == 1 because following
piece of code.

	      case TARGET_MEM_CONSTRAINT:
		/* Memory operands must be valid, to the extent
		   required by STRICT.  */
		if (MEM_P (op))
		  {
		    if (strict > 0
			&& !strict_memory_address_p (GET_MODE (op),
						     XEXP (op, 0)))
		      break;
		    if (strict == 0
			&& !memory_address_p (GET_MODE (op), XEXP (op, 0)))
		      break;
		    win = 1;
		  }
		/* Before reload, accept what reload can turn into mem.  */
		else if (strict < 0 && CONSTANT_P (op))
		  win = 1;
		/* During reload, accept a pseudo  */
		else if (reload_in_progress && REG_P (op)              <----HERE
			 && REGNO (op) >= FIRST_PSEUDO_REGISTER)
		  win = 1;
		break;


It means that even the recognized pattern only contains only "r" alternative,
the compiler still expect an "m" here to handle pseudo register produced by 
reload pass. Otherwise, it will have reload error.

In our porting, "movm" is implemented as define_expand. Register move and memory
move are implmeneted in different define_insn. Register move pattern has no
"m" alternative, and thus causes the "asm operand requires impossible reload".
I should merge these two patterns into one. 

Looking at the descrption of "movm" in internal manual, I found this subtle
requirement is not documented. Maybe we should add some text to avoid
future confusion. 

Cheers,
Bingfeng Mei
Broadcom UK



> -----Original Message-----
> From: Ian Lance Taylor [mailto:iant@google.com] 
> Sent: 01 May 2009 15:32
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org; bernd.schmidt@analog.com; weigand@de.ibm.com
> Subject: Re: Reload problem: asm operand requires impossible reload
> 
> "Bingfeng Mei" <bmei@broadcom.com> writes:
> 
> > I experienced "asm operand requires impossible reload" 
> error in our private porting. 
> > After digging into the reloading pass, I found something a 
> bit fishy. 
> >
> > The error message is produced in reload_as_needed function 
> (reload1.c)
> >
> > ...
> > 	      /* If this was an ASM, make sure that all the reload insns
> > 		 we have generated are valid.  If not, give an error
> > 		 and delete them.  */
> > 	      if (asm_noperands (PATTERN (insn)) >= 0)
> > 		for (p = NEXT_INSN (prev); p != next; p = NEXT_INSN (p))
> > 		  if (p != insn && INSN_P (p)
> > 		      && GET_CODE (PATTERN (p)) != USE
> > 		      && (recog_memoized (p) < 0
> > 			  || (extract_insn (p), ! 
> constrain_operands (1))))
> > 		    {
> > 		      error_for_asm (insn,
> > 				     "%<asm%> operand requires "
> > 				     "impossible reload");
> > 		      delete_insn (p);
> > 		    }
> > ...
> >
> > Here the code checks whether all generated reload insns are 
> valid. The "strict"
> > argument of the constraint_oeprands is set to 1, thus any 
> pseudo register operand
> > will fail the check if I understood correctly. However, at 
> this stage, all the 
> > generated reload instructions, including normal and asm 
> insns, seems to have 
> > pseudo register operands. Only later they are replaced by 
> memory operand. If I
> > disable this piece of code, the code is compiled without problem.
> >
> > Did I misunderstand something here, or is it an possible 
> bug? The code base is
> > GCC 4.4 branch. 
> 
> That code is only checking the insns which were created by
> emit_reload_insns, and after subst_reloads has run.  Those 
> instructions
> should not have any remaining references to pseudo-registers.  If they
> do, it means that reload is generating instructions which refer to
> pseudo-registers, and that would be wrong.  That check has been there
> for several releases, so I don't think it is obviously buggy.
> 
> If this is still puzzling we may need to see an example.
> 
> Ian
> 
>