This is an archive of the discontinued LLVM Phabricator instance.

[NFC][ScheduleDAG] Remove unused EntrySU SUnit
ClosedPublic

Authored by thegameg on Sep 17 2020, 3:55 PM.

Details

Summary

EntrySU doesn't seem to be used at all when building the ScheduleDAG.

Diff Detail

Event Timeline

thegameg created this revision.Sep 17 2020, 3:55 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 17 2020, 3:55 PM
thegameg requested review of this revision.Sep 17 2020, 3:55 PM
dmgreen accepted this revision.Sep 18 2020, 6:48 AM
dmgreen added a subscriber: dmgreen.

Sounds good to me.

This revision is now accepted and ready to land.Sep 18 2020, 6:48 AM
fhahn accepted this revision.Sep 18 2020, 7:23 AM

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.

LGTM

This revision was automatically updated to reflect the committed changes.
materi added a subscriber: materi.Sep 21 2020, 6:52 AM

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?

fhahn added a comment.Sep 22 2020, 6:55 AM

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.