This is an archive of the discontinued LLVM Phabricator instance.

[MachineScheduler] Add a flag to enable scheduling of cfi instructions
AbandonedPublic

Authored by tellenbach on Oct 8 2019, 6:50 AM.

Details

Summary

Add a flag --schedule-cfiinstrs to enable the scheduling of cfi
instructions during instruction scheduling.

If this flag is set to false (the current default) cfi instructions
act as scheduling boundaries during instruction scheduling. This can
lead to different scheduling regions and therefore differing generated
assembly, depending on the presence of cfi instructions.

Since some targets insert cfi instructions when debug information is
generated, but not if not, the scheduling of cfi instructions leads to
improved consistency between debug and non-debug mode.

See also: http://lists.llvm.org/pipermail/llvm-dev/2019-September/135433.html

This resolves PR37240.

Event Timeline

tellenbach created this revision.Oct 8 2019, 6:50 AM
tellenbach edited the summary of this revision. (Show Details)Oct 8 2019, 6:52 AM
jmorse added a subscriber: jmorse.Oct 8 2019, 7:00 AM
fhahn added a subscriber: fhahn.Oct 8 2019, 7:06 AM

I've not looked to closely yet, but isn't that basically the same we do for debug values? If that's the case, I think we should consider unifying the code to handle debug & CFI. Specifically, would it be possible to just extend the current handling of debug instructions to also handle CFI instructions? That should some renaming and a few code changes. I think.

llvm/lib/CodeGen/MachineScheduler.cpp
453

Can that be folded into the return, like the other conditions? Also, please update the comment with details about CFIInstructions.

I've not looked to closely yet, but isn't that basically the same we do for debug values? If that's the case, I think we should consider unifying the code to handle debug & CFI. Specifically, would it be possible to just extend the current handling of debug instructions to also handle CFI instructions? That should some renaming and a few code changes. I think.

You are absolutely correct, this is essentially the same as for debug values with the addition that it can be disabled. I will try to unify both approaches, maybe both loops (currently one for the vector of debug values and one for the vector of cfi instructions) can be fused into one.

fhahn added a comment.Oct 8 2019, 7:38 AM

I've not looked to closely yet, but isn't that basically the same we do for debug values? If that's the case, I think we should consider unifying the code to handle debug & CFI. Specifically, would it be possible to just extend the current handling of debug instructions to also handle CFI instructions? That should some renaming and a few code changes. I think.

You are absolutely correct, this is essentially the same as for debug values with the addition that it can be disabled. I will try to unify both approaches, maybe both loops (currently one for the vector of debug values and one for the vector of cfi instructions) can be fused into one.

I think we could just use the same map for both debug and CFI instructions and then just rename placeDebugInstruction to something like placeUnscheduledInstructions.

tellenbach updated this revision to Diff 223881.Oct 8 2019, 9:16 AM

Move test for scheduling boundaries into return statement

tellenbach marked an inline comment as done.Oct 8 2019, 9:18 AM
probinson added inline comments.Oct 8 2019, 10:58 AM
llvm/lib/CodeGen/MachineScheduler.cpp
445

"If <something>, <they> act as scheduling boundaries, otherwise they do." There seems to be a "not" missing somewhere.

llvm/lib/CodeGen/ScheduleDAGInstrs.cpp
825

I realize you are planning to rework this to handle CFI and DBG instructions more in the same way. But the tests don't appear to exercise the case of having a mix of CFI and DBG instructions, and I am not sure the current code will correctly handle all cases where CFI and DBG instructions are adjacent.

tellenbach abandoned this revision.Oct 10 2019, 3:32 AM

Thanks for your comments. Since I don't think changing instruction scheduling can fix the problem anymore I abandon this revision.

See also: http://lists.llvm.org/pipermail/llvm-dev/2019-October/135813.html