This is the mail archive of the gcc-patches@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: [PATCH] Fix DCE REG_LIBCALL note moving from noop move insns (PR rtl-optimization/33644)


On Thu, Oct 18, 2007 at 07:46:21AM -0400, Richard Kenner wrote:
> > I think that this is the fundamental point. Danny and I have taken the
> > view that it is not correct to insert instructions into a libcall. And
> > during the dataflow branch developement, we corrected as many of these
> > as we encountered.  
> 
> I want to avoid confusion here and be clear that we're talking about
> UNRELATED insns inside a libcall.  Clearly if, for example, you have to
> generate a reload for an insn inside a libcall, the appropriate place
> for it is inside the libcall.

That's even more confusing.
PR33644 is about virtual reg instantation pass adding RELATED insn inside
the libcall sequence (though without LIBCALL_ID note, from what I see
no pass after expand adds them, just combine redistributes them).  That
RELATED insn is later on changed into UNRELATED by fwprop1.
So, is in this case acceptable to add the UNRELATED insn into the sequence
(and should each pass in that case add LIBCALL_ID notes)?  The problem
with adding LIBCALL_ID note is that it won't then be deleted as useless
if it becomes useless.

If we decide that e.g. all insns in between REG_LIBCALL/REG_RETVAL noted
insns must have REG_LIBCALL_ID notes, then IMNSHO we should enforce it
with --enable-checking, that's the only reasonable way to make sure problems
are caught up quickly.

	Jakub


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