EntrySU doesn't seem to be used at all when building the ScheduleDAG.
This looks indeed unused, thanks for cleaning this up! There may be downstream targets that make use of EntrySU, but if that's the case it is easy to revert.
Our out-of-tree backend is currently using EntrySU for working with inter-region latencies.
When there is a long latency between two regions, we add an artificial edge from EntrySU to the successor SU with the appropriate latency. Then the scheduler has a chance to avoid the stall. The scheduler here is a custom out-of-tree variant for our in-order VLIW target.
If EntrySU is removed we would have to work on another way to handle these types of latencies. Does anyone know of a simpler or better way of doing it?
I also maintain an out-of-tree backend that relied on the EntrySU. Like materi, I used it to track inter-region latencies. I would be happy to update my code track these latencies in some other way. Please advise. Thanks
I am totally fine with keeping this in-tree, even unused, if it helps several out-of-tree backends. Thanks for speaking up.
Maybe someone using it can provide an explanation of potential uses of this node as a comment in ScheduleDAG.h?
It's perfectly fine to keep it, but it would be good to have something use it in tree upstream, otherwise we have zero test coverage.
Our backend is using EntrySU the same way as described by another poster above: to add top edges to adjust for clearances to the basic block entry. When removing this, we need to add our own EntrySU, but this becomes tricky because the scheduler will try to schedule it and release the node. I think it does make sense to keep EntrySU in-tree. Thanks for that.