[PATCH] D91929: [VE] Clean canRealignStack implementation

[Kazushi Marukawa via Phabricator via llvm-commits]

kaz7 created this revision.
kaz7 added reviewers: simoll, k-ishizaka.
kaz7 added projects: LLVM, VE.
Herald added subscribers: llvm-commits, hiraditya.
kaz7 requested review of this revision.

Old canRealignStack calls TRI::canRealignStack and hasReservedCallFrame.
But, this hasReservedCallFrame return true whenever for VE since VE
allocates call frame all the time.  It means this canRealignStack is
identical to TRI::canRealignStack.  This patch removes VE's
canRealignStack and let caller call TRI::canRealignStack directly.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D91929

Files:
  llvm/lib/Target/VE/VERegisterInfo.cpp
  llvm/lib/Target/VE/VERegisterInfo.h


Index: llvm/lib/Target/VE/VERegisterInfo.h
===================================================================
--- llvm/lib/Target/VE/VERegisterInfo.h
+++ llvm/lib/Target/VE/VERegisterInfo.h
@@ -40,8 +40,6 @@
                            RegScavenger *RS = nullptr) const override;
 
   Register getFrameRegister(const MachineFunction &MF) const override;
-
-  bool canRealignStack(const MachineFunction &MF) const override;
 };
 
 } // namespace llvm
Index: llvm/lib/Target/VE/VERegisterInfo.cpp
===================================================================
--- llvm/lib/Target/VE/VERegisterInfo.cpp
+++ llvm/lib/Target/VE/VERegisterInfo.cpp
@@ -174,26 +174,3 @@
 Register VERegisterInfo::getFrameRegister(const MachineFunction &MF) const {
   return VE::SX9;
 }
-
-// VE has no architectural need for stack realignment support,
-// except that LLVM unfortunately currently implements overaligned
-// stack objects by depending upon stack realignment support.
-// If that ever changes, this can probably be deleted.
-bool VERegisterInfo::canRealignStack(const MachineFunction &MF) const {
-  if (!TargetRegisterInfo::canRealignStack(MF))
-    return false;
-
-  // VE always has a fixed frame pointer register, so don't need to
-  // worry about needing to reserve it. [even if we don't have a frame
-  // pointer for our frame, it still cannot be used for other things,
-  // or register window traps will be SADNESS.]
-
-  // If there's a reserved call frame, we can use VE to access locals.
-  if (getFrameLowering(MF)->hasReservedCallFrame(MF))
-    return true;
-
-  // Otherwise, we'd need a base pointer, but those aren't implemented
-  // for VE at the moment.
-
-  return false;
-}


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D91929.306898.patch
Type: text/x-patch
Size: 1697 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20201122/37760e92/attachment.bin>