similar to: [LLVMdev] Getting the Stack Pointer

On Tue, 4 Mar 2008, David Greene wrote: > What's the "right" way to find out which machine register acts as the > stack pointer? I'm working on enhancing Fernando's register allocator > debugger and would like to add support for stack pointer semantics. > > TargetRegisterInfo has a getFrameRegister method but that returns > (on x86) either ESP/RSP or

On Tuesday 04 March 2008 12:16, Chris Lattner wrote: > > Would it be ok to add a getStackPointerRegister method to > > TargetRegisterInfo? > > Why do you need to do this in a register allocator? Typically you want to > refer to abstract frame indices. Wouldn't fernando's debugger use a > similar representation? I don't need it in the allocator. I need it in

On Sep 11, 2009, at 3:31 PM, David Greene wrote: > Attached is a patch to print asm comments for spill information. > We've discussed the mechanisms before but I wanted to run the > patch by everyone before I start to commit pieces. Some thoughts: The general approach to enhancing CreateStackObject and adding MachineInstr::AsmPrinterFlags seems fine to me! The testcase should

Hi guys, I have been using a debugger for my register allocator. The debugger happened to be very useful at catching register assignment errors. I've put the debugger on-line, if anyone who is working with register allocation wants to use. The debugger itself has nothing to do with LLVM, but I've coded a spiller that prints the code in a format that the debugger can read. The

On Wed, Dec 9, 2015 at 3:02 PM Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Derek Schuff via llvm-dev" <llvm-dev at lists.llvm.org> > > To: llvm-dev at lists.llvm.org > > Sent: Wednesday, December 9, 2015 4:31:31 PM > > Subject: [llvm-dev] Allowing virtual registers after register allocation > > > >

On Aug 17, 2007, at 4:17 PM, Fernando Magno Quintao Pereira wrote: > > Hi guys, > > I have been using a debugger for my register allocator. The > debugger > happened to be very useful at catching register assignment errors. > I've > put the debugger on-line, if anyone who is working with register > allocation wants to use. The debugger itself has nothing to

> On Dec 9, 2015, at 4:13 PM, Quentin Colombet <qcolombet at apple.com> wrote: > > Hi, > > I would actually go the other direction, i.e., stick to physical registers but with an infinite number. > The rational is that after register allocation we broke all the nice properties of the pre-alloc virtual registers. For instance, the existing liveness algorithm cannot be used

On 10/10/11 19:19, Jakob Stoklund Olesen wrote: > On Oct 10, 2011, at 10:26 AM, Richard Osborne wrote: >> I'm investigating a bug associated with debug information that manifests >> itself in the XCore backend (PR11105). I'd like to understand what the >> expected behavior of eliminateFrameIndex() is when it is called on a >> dbg_value machine instruction. >

Attached is a patch to print asm comments for spill information. We've discussed the mechanisms before but I wanted to run the patch by everyone before I start to commit pieces. -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: spillcomments.patch Type: text/x-diff Size: 58930 bytes Desc: not available URL:

Hi all, Virtual ISAs such as WebAssembly and NVPTX use infinite virtual register sets instead of traditional phsyical registers. PrologEpilogInserter is run after register allocation and asserts that all virtuals have been allocated but doesn't otherwise depend on this if scavenging is not needed. We'd like to use the target-independent PEI code for WebAssembly, so we're proposing a

Hi, Nicolas > Could you point me where those hooks are in the llvm code? I didn't find > any. Look into PrologEpilogInserter.cpp::PEI::runOnMachineFunction(). There are calls to hooks inside TargetRegisterInfo: TargetRegisterInfo::processFunctionBeforeCalleeSavedScan() and TargetRegisterInfo::processFunctionBeforeFrameFinalized(). Maybe they are not so convenient when working via JIT

On Monday 14 September 2009 12:32, Chris Lattner wrote: > On Sep 11, 2009, at 3:31 PM, David Greene wrote: > > Attached is a patch to print asm comments for spill information. > > We've discussed the mechanisms before but I wanted to run the > > patch by everyone before I start to commit pieces. > > Some thoughts: > > The general approach to enhancing

Thanks for all the hints Jakob, I've added the following piece of code after the spill code handling inside selectOrSplit() (ignoring some control logic): for (LiveIntervals::const_iterator I = LIS->begin(), E = LIS->end(); I != E; ++I) { unsigned VirtReg = I->first; if ((TargetRegisterInfo::isVirtualRegister(VirtReg)) && (VRM->getPhys(VirtReg)

I've been playing around with spillers and found that the SimpleSpiller fails badly on a particular code. The problem arises because SimpleSpiller does the test VRM.isAssignedReg(virtReg) which is implemented as: 00183 bool isAssignedReg(unsigned virtReg) const { 00184 if (getStackSlot(virtReg) == NO_STACK_SLOT && 00185 getReMatId(virtReg) == NO_STACK_SLOT)

Hello, This patch was reverted and the revert was forgotten to be undone after the performance regression it introduced was fixed. Can someone please revert it back (i.e. increase the max physreg size to 16K or even better to 32K) to enable us to experiment with large register number machines again? :) It was this trivial patch: Index: include/llvm/Target/TargetRegisterInfo.h

On Oct 10, 2011, at 10:26 AM, Richard Osborne wrote: > I'm investigating a bug associated with debug information that manifests > itself in the XCore backend (PR11105). I'd like to understand what the > expected behavior of eliminateFrameIndex() is when it is called on a > dbg_value machine instruction. That is up to the target. The TII::emitFrameIndexDebugValue() hook is

Dear, I have been going through the Targets registered with llvm. As I was looking around, I found an include statement in the file XXXRegisterInfo.h (XXX is any target), #include "llvm/Target/TargetRegisterInfo.h" The question is there is no folder called Target in my llvm directory (file TargetRegistorInfo.h missing ) and still programs compile in the XXX architecture. I want access

> On Dec 10, 2015, at 9:39 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > > > ----- Original Message ----- >> From: "Quentin Colombet" <qcolombet at apple.com> >> To: "Derek Schuff" <dschuff at google.com> >> Cc: "Hal Finkel" <hfinkel at anl.gov>, llvm-dev at lists.llvm.org >> Sent: Wednesday, December

Hi Anton, Anton Korobeynikov wrote: > I don't see any huge problems with writing such pass: just create > stack frame objects at fixed offsets inside your MF pass - and you'll > done. The only problem is that you need to do this early - before > prologue / epilogue inserter code runs, since afterwards stack frame > layout is almostly finalized (at "high level")

Hi, In the runtime system for GHC Haskell, the stack pointer register is not the same as the one defined by the operating system ABI, and it's difficult for GHC to change that. Following the example of CoreCLR in LLVM, it seems one way to remedy this situation is to define a new ABI (i.e., a new llvm::Triple::EnvironmentType ) and modify the code generator as-needed to respect to our ABI,