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

[Kenneth Zadeck]

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.