search for: targetframelow

...wering, since it's being used during prolog/epilog insertion. Moving it there would avoid the code duplication and possibly other layering problems. What do you think Eli P.S. I'm asking in llvmdev before proposing an actual patch because this change will affect all targets. P.S.2 Alas, TargetFrameLowering is not documented in http://llvm.org/docs/CodeGenerator.html

Heads up for out-of-tree targets: in r265036, TargetFrameLowering::eliminateCallFramePseudoInstr changed to return an iterator to the next instruction, instead of returning void. If your target was previously doing "MBB.erase(I); return;" your code should now be doing "return MBB.erase(I);". Thanks, Hans

> ISTM that eliminateCallFramePseudoInstr belongs in > TargerFrameLowering, since it's being used during prolog/epilog > insertion. Moving it there would avoid the code duplication and > possibly other layering problems. > What do you think Go ahead and move. It's s historical artifact why it is inside TRI. -- With best regards, Anton Korobeynikov Faculty of Mathematics

## Problem description One of the responsibilities of a target's implementation of TargetFrameLowering::emitPrologue is to set the frame pointer (if needed). Typically, the frame pointer will be stored to the stack just like the other callee-saved registers, and emitPrologue must insert the instruction to change its value after it was stored to the stack. Mips does this by looking at the number...

Hello, I want to use ProfileSummaryInfo in a class which is not a LLVM pass like TargetFrameLowering class (lib/CodeGen/TargetFrameLoweringImpl.cpp) one way I know to get ProfileSummaryInfo is getAnalysis<ProfileSummaryInfoWrapperPass>().getPSI(M); but I can't use this. Is this really possible? Sincerely, Vivek -------------- next part -------------- An HTML attachment was scrub...

...{ const TargetMachine &TM = Fn.getTarget(); assert(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 && !...

...lling and > being called across translation unit boundaries. The details about how this > contract is fulfilled are part of CodeGen IMO but do not need to be visible > at the IR level. > - The only thing we want to influence here is which registers are saved by > the callee. Changing TargetFrameLowering::determineCalleeSaves() is a good > place to achieve this without affecting unrelated things like parameter and > return value handling which would be part of the calling convention. > Hello Matthias, As per our discussion, the above trick will make sure that there is no callee saved...

...ow parameters should be passed or any special rule for return value etc , it just required to set callee saved registers to be none. So what are the minimal things required to define such a CC? Other alternative that I have thought was to add new attribute for function and use it like following in TargetFrameLowering::determineCalleeSaves() // In Naked functions we aren't going to save any registers. if (MF.getFunction()->hasFnAttribute(Attribute::Naked)) return; Any suggestions / thoughts are welcomed ! Sincerely, Vivek -------------- next part -------------- An HTML attachment was scrubb...

...ou can say the prologue is ended. --paulr > > > On Feb 17, 2017, at 3:33 AM, Alex Bradbury via llvm-dev <llvm- > dev at lists.llvm.org> wrote: > > > > ## Problem description > > > > One of the responsibilities of a target's implementation of > > TargetFrameLowering::emitPrologue is to set the frame pointer (if > needed). > > Typically, the frame pointer will be stored to the stack just like the > other > > callee-saved registers, and emitPrologue must insert the instruction to > change > > its value after it was stored to the s...

...back-end objects themselves (e.g., `use-soft-float'). -------------------------------------------------------------------------------- Before we get further, here are a few definitions used in this document: Back-end Objects :: Objects that affect code generation --- e.g., TargetInstrInfo, TargetFrameLowering, DataLayout, etc. CGContext :: A central repository for back-end objects. The back-end objects may change, so they should not be "cached" by individual passes. This is analogous to the current TargetMachine object. The term "CGContext" is used because it separates the cur...

...getMachine &TM = Fn.getTarget(); > assert(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(); > &g...

...r.cpp index 5ffb8f2..cc2ca87 100644 --- a/lib/CodeGen/StackSegmenter.cpp +++ b/lib/CodeGen/StackSegmenter.cpp @@ -40,7 +40,10 @@ void StackSegmenter::getAnalysisUsage(AnalysisUsage &info) const { } bool StackSegmenter::runOnMachineFunction(MachineFunction &MF) { - return false; + const TargetFrameLowering &TFI = *MF.getTarget().getFrameLowering(); + TFI.adjustForSegmentedStacks(MF); + // adjustForSegmentedStacks always changes the MachineFunction + return true; } FunctionPass *llvm::createStackSegmenter() { -- Sanjoy Das http://playingwithpointers.com

Mehdi, I am perusing the 3.8 trunk sources, and don’t find evidence where I would expect it for LLVM “downgrading” a function’s calling convention. PrologEpilogEmitter() { “CodeGen/” ... TFI->determineCalleeSaves() { “Target/XYZ/” TargetFrameLowering::determineCalleeSaves() { “CodeGen/” Return <<< some object derived from “*CallingConv.td” >>>; “build/lib/Target/XYX/” } ... SavedRegs.set(Reg); // to “add” a reg, EG for ‘hasFP’, ETC ... } } The SavedR...

...ation would make sense ? If so, we'll > > do that and change the safestack tests to use opt instead of llc. > > I tried to move the SafeStack to lib/Transform/Instrumentation, but I > realized that the SafeStack pass depends on TargetMachine: it gets the > stack alignment from TargetFrameLowering and the location of the unsafe > stack pointer from TargetLowering. It seems that making TargetMachine > available in opt would require opt to depend on more things from CodeGen > than it normally should. > Nick, please comment on TargetMachine in LLVM. Can we get stack alignment...

...0:49: error: expected class-name before ‘{’ token PPCSubtarget.h:196:30: error: ‘RegClassVector’ has not been declared In file included from AArch64Subtarget.cpp:14:0: AArch64Subtarget.h:29:57: error: expected class-name before ‘{’ token PPCFrameLowering.h: In member function ‘virtual const llvm::TargetFrameLowering::SpillSlot* llvm::PPCFrameLowering::getCalleeSavedSpillSlots(unsigned int&) const’: PPCFrameLowering.h:138:51: error: ‘X31’ is not a member of ‘llvm::PPC’ I'm using the same configure I did for 3.2 (well, I didn't explicitly set gcc before): export REQUIRES_RTTI=1 export REQUIRE...

I need to use ‘createVirtualRegister’ for a specific case in my ‘eliminateFrameIndex’ function implementation. However, whenever that code is executed, I get the assertion "MachineCopyPropagation should be run after register allocation!” at a later stage. I have seen that at least a couple of backend implementations (including ARM Thumb) create virtual registers in ‘eliminatedFrameIndex’.

...; > if (!TFI->isStackRealignable()) <--- new line > > Align = std::min(Align, StackAlign); > > > > Is this a bug or am I missing something? > > > > This looks like a bug. By default, isStackRealignable() always > returns true (this default comes from the TargetFrameLowering > constructor). I wonder, however, is this is not correctly > implemented in some backends (X86RegisterInfo::canRealignStack, for > example, is not completely trivial). Nadav, do you know how this > works? [Trying some other relevant people...] Chad, Jakob: thoughts? -Hal >...

...g to do, and meanwhile I'm going to try to prepare a patch > that does this. I've gone ahead and done this. With the attached patch applied, nothing in lib/Target/* or include/llvm/Target/* include anything from include/llvm/CodeGen. The .cpp files that moved are TargetELFWriterInfo, TargetFrameLowering, TargetLoweringObjectFile, TargetMachine, TargetOptions, TargetRegisterInfo and TargetSubtargetInfo. The .h files that moved are the matching headers for the .cpp files plus TargetInstrInfo, TargetSelectionDAGInfo and TargetLowering. Please review! More generally, I suggest reviewing the...

Hello LLVM Community, To improve Interprocedural Register Allocation (IPRA) we are trying to force caller saved registers for local functions (which has likage type local). To achive it I have modified TargetFrameLowering::determineCalleeSaves() to return early for function which satisfies if (F->hasLocalLinkage() && !F->hasAddressTaken()) and also reflecting the fact that for local function there are no caller saved registers I am also changing RegUsageInfoCollector.cpp to not to mark regiseters...

...ler-save will fix the problem. > > if (!TFI->isStackRealignable()) <--- new line > Align = std::min(Align, StackAlign); > > Is this a bug or am I missing something? > This looks like a bug. By default, isStackRealignable() always returns true (this default comes from the TargetFrameLowering constructor). I wonder, however, is this is not correctly implemented in some backends (X86RegisterInfo::canRealignStack, for example, is not completely trivial). Nadav, do you know how this works? -Hal > > Thanks, > Francois Pichet, Octasic. > > ___________________________...