> -----Original Message-----
> From: Ian Lance Taylor [mailto:i...@google.com] 
> Sent: 01 May 2009 15:32
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org; bernd.schm...@analog.com; weig...@de.ibm.com
> Subject: Re: Reload problem: asm operand requires impossible reload
> 
> "Bingfeng Mei" <b...@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

Yes, I understand that. 
 
> 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

Actually, they do contain references to pseudo-registers. Only in following
code (reload function in reload1.c, after the reload_as_needed function
that emits error message), pseudo registers are replaced with requivalent
memory operands.

  /* Now eliminate all pseudo regs by modifying them into
     their equivalent memory references.
     The REG-rtx's for the pseudos are modified in place,
     so all insns that used to refer to them now refer to memory.

     For a reg that has a reg_equiv_address, all those insns
     were changed by reloading so that no insns refer to it any longer;
     but the DECL_RTL of a variable decl may refer to it,
     and if so this causes the debugging info to mention the variable.  */
  for (i = FIRST_PSEUDO_REGISTER; i < max_regno; i++)
    {
      rtx addr = 0;

      if (reg_equiv_mem[i])
        addr = XEXP (reg_equiv_mem[i], 0);

      if (reg_equiv_address[i])
        addr = reg_equiv_address[i];

      if (addr)
        {
          if (reg_renumber[i] < 0)
            {
              rtx reg = regno_reg_rtx[i];

              REG_USERVAR_P (reg) = 0;
              PUT_CODE (reg, MEM);
              XEXP (reg, 0) = addr;
              if (reg_equiv_memory_loc[i])
                MEM_COPY_ATTRIBUTES (reg, reg_equiv_memory_loc[i]);
              else
                {
                  MEM_IN_STRUCT_P (reg) = MEM_SCALAR_P (reg) = 0;
                  MEM_ATTRS (reg) = 0;
                }
              MEM_NOTRAP_P (reg) = 1;
            }
          else if (reg_equiv_mem[i])
            XEXP (reg_equiv_mem[i], 0) = addr;
        }
    }

> for several releases, so I don't think it is obviously buggy.
> 
> If this is still puzzling we may need to see an example.
> 
I will try to produce an example for other targets.

> Ian
> 
> 




Reply via email to