-
Notifications
You must be signed in to change notification settings - Fork 13.7k
[TII][X86] Do not schedule frame-setup/frame-destory instructions #96611
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
frame-setup/frame-destroy instruction can not be scheduled around by PostRAScheduler. Their order is critical for SEH.
Test case is related to schedule model is not easy to create. |
@llvm/pr-subscribers-backend-x86 Author: Haohai Wen (HaohaiWen) Changesframe-setup/frame-destroy instruction can not be scheduled around by Full diff: https://github.com/llvm/llvm-project/pull/96611.diff 1 Files Affected:
diff --git a/llvm/lib/Target/X86/X86InstrInfo.cpp b/llvm/lib/Target/X86/X86InstrInfo.cpp
index 1a43d5c17080e..069a1ec9a5988 100644
--- a/llvm/lib/Target/X86/X86InstrInfo.cpp
+++ b/llvm/lib/Target/X86/X86InstrInfo.cpp
@@ -8832,6 +8832,11 @@ bool X86InstrInfo::isSchedulingBoundary(const MachineInstr &MI,
Opcode == X86::PLDTILECFGV)
return true;
+ // Frame setup and destory can't be scheduled around.
+ if (MI.getFlag(MachineInstr::FrameSetup) ||
+ MI.getFlag(MachineInstr::FrameDestroy))
+ return true;
+
return TargetInstrInfo::isSchedulingBoundary(MI, MBB, MF);
}
|
@@ -8832,6 +8832,11 @@ bool X86InstrInfo::isSchedulingBoundary(const MachineInstr &MI, | |||
Opcode == X86::PLDTILECFGV) | |||
return true; | |||
|
|||
// Frame setup and destory can't be scheduled around. | |||
if (MI.getFlag(MachineInstr::FrameSetup) || | |||
MI.getFlag(MachineInstr::FrameDestroy)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we put it in TargetInstrInfo::isSchedulingBoundary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lots of arm tests would fail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If arm accepts scheduling with frame setup and destory, why can't for X86?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Failed arm tests: https://buildkite.com/llvm-project/github-pull-requests/builds/75530#01904eb7-13d0-451e-b1da-bcb86cd44b60
.seh_savexmm %xmm15, 544
.seh_endprologue
For X86, most of frame-setup instruction is related to SEH exception restore.
Changing part of its order does not matter. e.g. two independent register save instructions.
Part of them does matter. e.g. .seh_pushreg, moving .seh_endprologue which may affect prologue size.
Anyway, rescheduling frame-setup instruction does not look like profitable for X86.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't see the reason from the log, but I'm good with this change as long as no performance regression for X86.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Thanks |
…vm#96611) frame-setup/frame-destroy instruction can not be scheduled around by PostRAScheduler. Their order is critical for SEH.
…vm#96611) frame-setup/frame-destroy instruction can not be scheduled around by PostRAScheduler. Their order is critical for SEH.
frame-setup/frame-destroy instruction can not be scheduled around by
PostRAScheduler. Their order is critical for SEH.