This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]