[PATCH] Fix DCE REG_LIBCALL note moving from noop move insns (PR rtl-optimization/33644)

Richard Kenner kenner@vlsi1.ultra.nyu.edu
Thu Oct 18 12:09:00 GMT 2007


> 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.

I'd phrase it this way: a libcall is a sequence of insns that implement
a particular "thing".  It's perfectly valid to rearrange that sequence or
to expand or contract the number of insns in that sequence as long as they
are all part of the implementation of the "thing".  What is NOT valid is
to move some of that sequence outside of the libcall range or to move
insns that are not part of that implementation inside the libcall range.

Unfortunately, this DOES produce the problem that Eric was talking about,
which is the need for any optimization that changes insns inside a libcall
to track the fact that they are part of the libcall. But I think that's
unavoidable.



More information about the Gcc-patches mailing list