search for: getframeinfo

...ing redundant code ofcourse bloats the generated code... Would it be possible to conditionally enable the register scavenger only if the function has a big stack? It now gets unconditionally enabled in SPURegisterInfo::requiresRegisterScavenging(const MachineFunction &MF). Just checking MF.getFrameInfo()->getStackSize() here doesn't seem to be the solution... kalle -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bigstack.ll URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100226/2e97950d/attachment.ksh>

...n the backend cpp files, I now get compilation errors, not only when trying to print floats but also in other places. For example, for the code bool ADRESRegisterInfo::hasReservedCallFrame(const MachineFunction &MF) const { dbgs() << "hasReservedCallFrame() = " << !MF.getFrameInfo()->hasVarSizedObjects() << "\n"; return !MF.getFrameInfo()->hasVarSizedObjects(); } I get llvm[0]: Compiling ADRESRegisterInfo.cpp for Debug+Asserts build /work/llvm/trunk/llvm/lib/Target/ADRES/ADRESRegisterInfo.cpp: In member function 'bool llvm::ADRESRegisterInfo::h...

...m. For the sake of simplicity I decided not to bother with stack register yet and instead I just emit FrameIndex as immediate: bool MyBackendDAGToDAGISel::SelectAddrFI(SDValue &N, SDValue &R) { if (N.getOpcode() != ISD::FrameIndex) return false; MachineFrameInfo &MFI = MF->getFrameInfo(); int FX = cast<FrameIndexSDNode>(N)->getIndex(); R = CurDAG->getTargetFrameIndex(FX, MVT::i32); return true; } This way I end up with store %r1, [1] and handle it in my CPU emulator accordingly. So, instead of matching that FrameIndex in store, I really want to emit a load f...

Hello > Would it be possible to conditionally enable the register scavenger only if > the function has a big stack? It now gets unconditionally enabled in >  SPURegisterInfo::requiresRegisterScavenging(const MachineFunction &MF). > Just checking MF.getFrameInfo()->getStackSize() here doesn't seem to be the > solution... Well, I think no. regscavenger should work well regardless of any settings. Currently it's heavily used for ARM, so, you might want to look how the stuff is solved there. -- With best regards, Anton Korobeynikov Faculty of...

...argetRegisterClass *RC, const TargetRegisterInfo *TRI ) const { PR_FUNCTION(); DebugLoc DL; if (MI != MBB.end()) DL = MI->getDebugLoc(); MachineFunction &MF = *MBB.getParent();MF.dump(); MachineFrameInfo &MFI = *MF.getFrameInfo(); unsigned Align = MFI.getObjectAlignment(MVT::i8); MachineMemOperand *MMO = MF.getMachineMemOperand(MachinePointerInfo::getFixedStack(MVT::i8), MachineMemOperand::MOStore, MFI.getObjectSize(MVT::i8), Al...

Can you try making the constructor "explicit" for PrintReg in include/llvm/Target/TargetRegisterInfo.h. I think you were getting an implicit conversion there which should probably be fixed anyway. On Mon, Nov 26, 2012 at 11:47 PM, Bjorn De Sutter < bjorn.desutter at elis.ugent.be> wrote: > Hi, > > that solved my problem on trunk as well, thanks. Strange that you have to

Hi, Is it possible to add a spill code (a pair of store /load ) to the machinecode in a pass before the instruction emitter? If so, how can I calculate the address (offset to the sp) for the spill store/load instructions? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL:

...-jumping just to bypass const. Which of the above, or any other possibilities, would you consider to be the best approach? (While I'm on the topic of this function, it's a little bothersome that the MachineFunction &MF parameter is marked const also. It makes it impossible to call MF.getFrameInfo() without casting the constness away. In such cases, is it best to cast away const, or remove the qualifier from the parameter?) Thanks for any help! Bill -- Bill Schmidt, Ph.D. IBM Advance Toolchain for PowerLinux IBM Linux Technology Center wschmidt at us.ibm.com wschmidt at linux.vnet.ibm.com

Hi, that solved my problem on trunk as well, thanks. Strange that you have to include this though. Bjorn On 27 Nov 2012, at 00:00, Daniel Prokesch <daniel.prokesch at gmail.com> wrote: > Hi, > > I accidentally stumbled upon your post. > I observed similar behaviour whenever I did not include > > #include "llvm/Support/Debug.h" > #include

...all(const CallInst &I, unsigned Intrinsic) { setValue(&I, N); return nullptr; } + case Intrinsic::typeid_for: { + visitTypeidfor(I); + return nullptr; + } } } @@ -6769,6 +6773,29 @@ void SelectionDAGBuilder::visitPatchpoint(ImmutableCallSite CS, FuncInfo.MF->getFrameInfo()->setHasPatchPoint(); } +void SelectionDAGBuilder::visitTypeidfor(const CallInst &CI) { + SDValue Res; + static std::vector<const StructType *> StructTypes; + int ID = -1; + Value *PtrArg = CI.getArgOperand(0); + PointerType *PTy = cast<PointerType>(PtrArg->getType())...

On Thu, 17 Aug 2006, Anton Vayvod wrote: > Thanks, Ralph, this line worked well :) > Here it is, my first patch to LLVM :) > I've changed all allocation_order_begin() and allocation_order_end() methods > to take const MachineFunction &MF as a parameter. I also added const version > of MachineFunction::getInfo<Ty>() method. And I changed three static hasFP() >

...const TargetRegisterClass *RC, const llvm::TargetRegisterInfo*) const { DebugLoc DL; if (MI != MBB.end()) DL = MI->getDebugLoc(); MachineFunction &MF = *MBB.getParent(); MachineFrameInfo &MFI = *MF.getFrameInfo(); MachineMemOperand *MMO = MF.getMachineMemOperand(PseudoSourceValue::getFixedStack(FrameIdx), MachineMemOperand::MOStore, 0, MFI.getObjectSize(FrameIdx), MFI.getObjectAlignment(FrameIdx)); unsigned tmpVR...

On Feb 22, 2010, at 6:08 AM, Kalle.Raiskila at nokia.com wrote: > Hello all, > > currently the SPU backend does not handle big stack frames (>16*511 > bytes) nicely. llc asserts on malformed machine instructions. > (Assertion `MI->getOperand(OpNo).isImm() && "printDFormAddr first > operand is not immediate") Sounds fine to me in general. Please write a

...+ SaveArgs = STI.getSaveArgs(); } bool X86FrameLowering::hasReservedCallFrame(const MachineFunction &MF) const { @@ -83,7 +84,7 @@ /// or if frame pointer elimination is disabled. bool X86FrameLowering::hasFP(const MachineFunction &MF) const { const MachineFrameInfo &MFI = MF.getFrameInfo(); - return (MF.getTarget().Options.DisableFramePointerElim(MF) || + return (MF.getTarget().Options.DisableFramePointerElim(MF) || SaveArgs || TRI->needsStackRealignment(MF) || MFI.hasVarSizedObjects() || MFI.isFrameAddressTaken() || MFI.hasOpaqueSPAdjustment()...

Hello everybody, hi Evan, this patch changes the lowering of arguments for tail call optimized calls. Before arguments that could be overwritten by each other were explicitly lowered to a stack slot, not giving the register allocator a chance to optimize. Now a sequence of copyto/copyfrom virtual registers ensures that arguments are loaded in (virtual) registers before they are lowered to the

Hello all, currently the SPU backend does not handle big stack frames (>16*511 bytes) nicely. llc asserts on malformed machine instructions. (Assertion `MI->getOperand(OpNo).isImm() && "printDFormAddr first operand is not immediate") E.g. the function: define i32 @foo() nounwind { entry: %retval = alloca i32 %big_data = alloca [1000 x i32] store i32 3840, i32*

On Tue, Jun 21, 2016 at 12:31 AM, Matthias Braun <matze at braunis.de> wrote: > I just discussed this with vivek on IRC (and I think we agreed on this): > > Let me first state the motivation clearly to ease later discussions: > As far as the motivation for this change goes: Changing the calling > convention allows us to choose whether a register is saved by the callee or >

Paolo Invernizzi wrote: > There was a similar problem some time ago, and was resolved with alloca. > I think it's a better solution to use the stack instead of the heap... I tend to agree, but the constructors won't get called if it's an object array -- anyway, this particular case there was no objects, just pointers and bools so alloca should be fine. I'll leave it to

On Tue, Jun 25, 2019 at 9:59 AM Tim Northover <t.p.northover at gmail.com> wrote: > On Tue, 25 Jun 2019 at 06:26, Gleb Popov via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > >> While the store is being selected LLVM will just treat the value being > >> stored as a generic pointer-width integer unless you have written a > >> specific pattern for

...if (RC == &ARM::tGPRRegClass || (TargetRegisterInfo::isPhysicalRegister(SrcReg) && isARMLowRegister(SrcReg))) { DebugLoc DL; if (I != MBB.end()) DL = I->getDebugLoc(); MachineFunction &MF = *MBB.getParent(); MachineFrameInfo &MFI = *MF.getFrameInfo(); MachineMemOperand *MMO =