[llvm] [MachineCopyPropagation, Scheduler] Detect and fix suboptimal instruction order to enable optimizations (PR #98087)

[Gábor Spaits via llvm-commits]

spaits wrote:

I think that the logic I want to introduce here is orthogonal to the one that is already present in the anti dependency breaker. We couldn't reuse any logic from the anti dependency breaker. The anti dependencies are found and categorized by the ScheduleDAG. The only thing common between these two is that we both would check if a dependency is anti dependency:

> We are not breaking any anti dependency here. The anti dependencies stay, they must stay, in some cases they are not preventable. Anti dependencies must happen when we have a value, that must be in a specific register (for example the calling convention says so) or must come from a specific register (the calling convention specifies the return value storing register).

I think the best possible solution would be to use the existing scheduler DAG in the MCP. As @michaelmaitland has suggested:

> I wonder about adapting or reusing the ScheduleDAG in MCP. With this approach, I thought about the problem of rebuilding the graph multiple times. I'm not sure how expensive it is, but if we decided that it was too expensive, I wonder if it would be possible to reuse the same ScheduleDAG across multiple passes (i.e. build once and reuse). I think are building the graph multiple times today: once for pre-ra scheduling and once for post-ra scheduling. So that makes me believe that, at least initially, it might be okay to rebuild it a third time.

Also I don't think that the schedule dag building would cost that much. It may be built twice in the legacy post RA scheduler.

What I would do first is removing the dependency graph made by me.

I would use a `scheduleDAG` instead. So the re-implementation of the schedule graph would not happen.
By this I would address this concern of @qcolombet :

> My worry is that we don't track the right thing and we start breaking things or slowly but surely re-implement the whole DDG in MCP.

I will do a more in depth research to see whether any current variant of ScheduleDAG can handle the modification of the underlying MIR. If not then I may create a new subclass that does just that, or I will rebuild the ScheduleDAG at each instruction reordering.

Regardless of this I am still going to work on bringing the anti dependency breaker to the new scheduler. (I have already played around with it with less success).

@s-barannikov @qcolombet @michaelmaitland So what do you think of an implementation in MCP using the existing ScheduleDAG? To me it would be the most logical and we would get the most code reuse this way.

Thank you very much for your attention and response in advance.

https://github.com/llvm/llvm-project/pull/98087