search for: stackgrowsdown

...ert(TM.getRegisterInfo() && "TM::getRegisterInfo() must be implemented!"); const TargetInstrInfo &TII = *Fn.getTarget().getInstrInfo(); const TargetRegisterInfo &TRI = *TM.getRegisterInfo(); const TargetFrameLowering *TFI = TM.getFrameLowering(); bool StackGrowsDown = TFI->getStackGrowthDirection() == TargetFrameLowering::StackGrowsDown; int FrameSetupOpcode = TII.getCallFrameSetupOpcode(); int FrameDestroyOpcode = TII.getCallFrameDestroyOpcode(); if (RS && !FrameIndexVirtualScavenging) RS->enterBasicBlock(BB);...

...Offsets methods in CodeGen/PrologEpilogEmitter.cpp does not work for me, since it asserts if stack grows up, and when assert is commented out, allocates spill slots in the same location as function arguments, which is not right. I've tried to fix that, and a patches. It merely adds if (StackGrowsDown) everywhere, so that the current logic should not be alterted, and the logic when stack grows up is correct. I'd say that the patch is not as nice, due to those conditionals, but on the other hand the existing logic is a bit tricky, and I would not like to change it, especially since I hav...

...terInfo() && > "TM::getRegisterInfo() must be implemented!"); > const TargetInstrInfo &TII = *Fn.getTarget().getInstrInfo(); > const TargetRegisterInfo &TRI = *TM.getRegisterInfo(); > const TargetFrameLowering *TFI = TM.getFrameLowering(); > bool StackGrowsDown = > TFI->getStackGrowthDirection() == > TargetFrameLowering::StackGrowsDown; > int FrameSetupOpcode = TII.getCallFrameSetupOpcode(); > int FrameDestroyOpcode = TII.getCallFrameDestroyOpcode(); > > if (RS && !FrameIndexVirtualScavenging) RS->en...

...>> "TM::getRegisterInfo() must be implemented!"); >> const TargetInstrInfo &TII = *Fn.getTarget().getInstrInfo(); >> const TargetRegisterInfo &TRI = *TM.getRegisterInfo(); >> const TargetFrameLowering *TFI = TM.getFrameLowering(); >> bool StackGrowsDown = >> TFI->getStackGrowthDirection() == >> TargetFrameLowering::StackGrowsDown; >> int FrameSetupOpcode = TII.getCallFrameSetupOpcode(); >> int FrameDestroyOpcode = TII.getCallFrameDestroyOpcode(); >> >> if (RS && !FrameIndexVirtu...

..."TM::getRegisterInfo() must be implemented!"); >>> const TargetInstrInfo &TII = *Fn.getTarget().getInstrInfo(); >>> const TargetRegisterInfo &TRI = *TM.getRegisterInfo(); >>> const TargetFrameLowering *TFI = TM.getFrameLowering(); >>> bool StackGrowsDown = >>> TFI->getStackGrowthDirection() == >>> TargetFrameLowering::StackGrowsDown; >>> int FrameSetupOpcode = TII.getCallFrameSetupOpcode(); >>> int FrameDestroyOpcode = TII.getCallFrameDestroyOpcode(); >>> >>> if (RS &&a...

...getRegisterInfo() must be implemented!"); >>>> const TargetInstrInfo &TII = *Fn.getTarget().getInstrInfo(); >>>> const TargetRegisterInfo &TRI = *TM.getRegisterInfo(); >>>> const TargetFrameLowering *TFI = TM.getFrameLowering(); >>>> bool StackGrowsDown = >>>> TFI->getStackGrowthDirection() == >>>> TargetFrameLowering::StackGrowsDown; >>>> int FrameSetupOpcode = TII.getCallFrameSetupOpcode(); >>>> int FrameDestroyOpcode = TII.getCallFrameDestroyOpcode(); >>>> >>...

The X86 backend has this code: X86TargetMachine::X86TargetMachine(const Module &M, IntrinsicLowering *IL) : .... FrameInfo(TargetFrameInfo::StackGrowsDown, 8/*16 for SSE*/, 4), That is, it uses "4" as local area offset. Based on prior discussion this should mean that the local area starts and address ESP+4. Is this really true? On X86 stack grows down, so I'd expect local area to start below ESP, e.g. at ESP - 4, and ESP + 4 would c...

...==----------------------------------------------------------------------===// // Stack and context switching //===----------------------------------------------------------------------===// 4/07/2010 - Initial Revision 4/11/2010 - Introduced llvm.getcontextstacktop and llvm.stackgrowsdown, changed the definition of llvm.makecontext slightly, and added a discussion of context stack space use and possible strategies for minimizing total memory and address space reserved for stacks. At the time of this writing, LLVM supports standard function calls...

Kenneth Uildriks <kennethuil at gmail.com> wrote: > As I see it, the context switching mechanism itself needs to know > where to point the stack register when switching.  The C routines take > an initial stack pointer when creating the context, and keep track of > it from there.  If we don't actually need to interoperate with > contexts created from the C routines, we have

Hello, In MachineFrameInfo::print (llvm-6.0.0) line 235, when printing SP offsets, shouldn't it be // -> consider stack growth direction int64_t Off = StackGrowsDown ? SO.SPOffset - ValOffset : SO.SPOffset + ValOffset; Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180322/4e92d7d8/attachment.html>

On Wed, 9 Jun 2004, Vladimir Prus wrote: > > The X86 backend has this code: > > X86TargetMachine::X86TargetMachine(const Module &M, IntrinsicLowering *IL) > : .... > FrameInfo(TargetFrameInfo::StackGrowsDown, 8/*16 for SSE*/, 4), > > That is, it uses "4" as local area offset. Based on prior discussion this > should mean that the local area starts and address ESP+4. Is this really > true? On X86 stack grows down, so I'd expect local area to start below ESP, > e.g. at ESP - 4...

...Target &T, const std::string &TT, const std::string &FS) : LLVMTargetMachine(T, TT), Subtarget(TT, FS), DataLayout("e-p:16:8:8-i8:8:8-i16:8:8-i32:8:8"), InstrInfo(Subtarget), TLInfo(*this), FrameInfo(TargetFrameInfo::StackGrowsDown, 1, 0) { } Linking CXX executable ../../bin/llvm-mc cd /home/john/src/llvm_build/tools/llvm-mc && /usr/bin/cmake -E cmake_link_script CMakeFiles/llvm-mc.dir/link.txt --verbose=1 /usr/bin/c++ -g -fPIC CMakeFiles/llvm-mc.dir/llvm-mc.cpp.o CMakeFiles/llvm-mc.dir/AsmExpr.cpp.o CMakeFiles...