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: RFC: SMS problem with emit_copy_of_insn_after copying REG_NOTEs


> > Andrew Pinski <pinskia@physics.uc.edu> writes:
> > 
> > > > 
> > > > > Hi,
> > > > > thanks for testing.  I've bootstrapped/regtested this variant of patch
> > > > > and comitted it as obvious.
> > > > 
> > > > Since this is an insn, we should not be copying it as it is just a link to that
> > > > insn.
> > > > 
> > > > Attached is a patch which fixes the ICE though I have not bootstrapped and tested
> > > > it yet.
> > > 
> > > Lets try to attach the patch this time.
> > 
> > It seems to me this code should just be 
> > 
> >   for (link = REG_NOTES (insn); link; link = XEXP (link, 1))
> >     if (REG_NOTE_KIND (link) != REG_LABEL)
> >       {
> > 	if (GET_CODE (link) == EXPR_LIST)
> > 	  REG_NOTES (new)
> > 		= gen_rtx_EXPR_LIST (REG_NOTE_KIND (link),
> > 		  copy_rtx (XEXP (link, 0)),  REG_NOTES (new));
> > 	else
> > 	  REG_NOTES (new)
> > 	       = gen_rtx_INSN_LIST (REG_NOTE_KIND (link),
> > 		 copy_rtx (XEXP (link, 0)),  REG_NOTES (new));
> >       }
> > 
> > What do we expect to find in a REG_NOTE that requires the machinery of
> > copy_insn_1?  And calling copy_insn_1 without going through copy_insn
> > looks very wrong.
> 
> Here is a better patch which also speeds up this code by fixing up
> the libcall notes in that loop.
> 
> I tested it on the preprocessed source that Andreas sent me but
> I don't have time to do a full bootstrap till tommorrow.
> 
> ChangeLog:
> 
> 	* emit-rtl.c (emit_copy_of_insn_after): Copy REG_LIBCALL note specially.
> 	Copy REG_RETVAL not specially and fix it and the referencing REG_LIBCALL note.
> 	Use copy_rtx instead of copy_insn_1 for EXPR_LIST note.
> 	Abort if we get a INSN_LIST for the note.
> 
> Thanks,
> Andrew Pinski

Also I should mention, this also fixes a possible bug with libcalls that
are embedded in one another.  Before we were just assuming if we have a REG_RETVAL,
then the previous REG_LIBCALL would be the start of the libcall but that would be
incorrect with embedded libcalls.

Thanks,
Andrew Pinski


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