This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix DCE REG_LIBCALL note moving from noop move insns (PR rtl-optimization/33644)
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.
>
>
I assume that generally the optimizations that do this know that they
are doing.
The common code moving optimizations, i assume, want to treat libcalls
as black boxes.
> 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.
>
I actually did not know that there were such optimizations. I thought
that most of the back end treated libcalls as black boxes.