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

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

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

I don't see anything in that PR saying exactly how an optimizer is changing
a related insn to being unrelated (that seems wierd to me), so I can't
comment about the details here.  However, I saw this email before I got on
a plane and thought about it during the flight.

A "related" insns really doesn't need to be in a libcall since, by
definition, it feeds into one of the insns there.  So if the libcall is
moved or deleted, that insns will be processes similarly by whatever code
is moving or deleting the libcall.

In fact, I think we can view libcalls as anachronisms which we can replace
by a much simpler mechanism.  In the original compiler, we didn't have any
sort of good flow infrastructure, so they were the only way to indicate
that if we delete or move some insn, we have to do the same to others.
But now there are much better ways: all we need to do is to have a REG_NOTE
on the last insn in a libcall (the one with the REG_EQUAL) that lists (like
LOG_LINKS) the insns that need to be deleted or moved with it and *perhaps*
those insns need to point to that ending insn.  The rest can use existing
dataflow information.