This is an archive of the discontinued LLVM Phabricator instance.

MachineScheduler: Restore TopCand after comparing top and bottom candidates
AbandonedPublic

Authored by tstellarAMD on Aug 15 2016, 8:14 AM.

Details

Reviewers
MatzeB
Summary

In the GenericScheduler, before comparing top and bottom candidates, we set
TopCand.Reason to NoCand, so that we can determine wether or not it was selected
over BotCand. However, in the case where the bottom candidate is selected,
TopCand needs to have Reason restored to its original value, otherwise
the scheduler will continue selecting from the bottom, until a new
instruction is added to the Top queue.

Diff Detail

Event Timeline

tstellarAMD retitled this revision from to MachineScheduler: Restore TopCand after comparing top and bottom candidates.
tstellarAMD updated this object.
tstellarAMD added a reviewer: MatzeB.
tstellarAMD added a subscriber: llvm-commits.
MatzeB accepted this revision.Aug 15 2016, 11:57 AM
MatzeB edited edge metadata.

Good catch! LGTM.

This revision is now accepted and ready to land.Aug 15 2016, 11:57 AM
MatzeB requested changes to this revision.Aug 15 2016, 12:05 PM
MatzeB edited edge metadata.

Actually I am not so sure anymore. In cases where the topnode isn't picked the reason shouldn't matter, but we will reset the reason anyway next round when we compare against the top node again. Do you have an example that behaves differently with/without this patch? There may be something else wrong.

This revision now requires changes to proceed.Aug 15 2016, 12:05 PM

Actually I am not so sure anymore. In cases where the topnode isn't picked the reason shouldn't matter, but we will reset the reason anyway next round when we compare against the top node again. Do you have an example that behaves differently with/without this patch? There may be something else wrong.

pickNodeBidirectional() won't re-compare if topnode wasn't scheduled in the previous round.

Actually I am not so sure anymore. In cases where the topnode isn't picked the reason shouldn't matter, but we will reset the reason anyway next round when we compare against the top node again. Do you have an example that behaves differently with/without this patch? There may be something else wrong.

pickNodeBidirectional() won't re-compare if topnode wasn't scheduled in the previous round.

It will always compare the top and bottom pick. Even though one of them is possibly saved from last round they will be subject to a comparison so outdates/old data in the reason field shouldn't affect the decision.

tstellarAMD abandoned this revision.Sep 6 2016, 2:00 PM