search for: framepointer

...a double check, as I am not 100% sure to have updated correctly the LiveInterval information. In terms of registers, the Femto target is simplistic : a single register class GR16, for data and pointers, all i16. It has 16 registers, R0 to R15; R15 is used as stack pointer, and R14 potentialy as framepointer. A pair is constituted from a register + its successor, i.e. (R0, R1), (R1,R2), (R2, R3), ... are valid pairs. This is an instruction encoding constraint, as we only have 16bits wide instructions. Pairs involving R15 are never allowed, those with R14 may be allowed, depending on each function....

...ogram pulls in a substantial amount of library code (i/o libraries, container classes, root-level exception handling, argv handling, garbage collection runtime code, and so on.) It may be something as simple as me doing something stupid in my build script, (although I did remember to use -fno-omit-framepointer). I suppose I should mention one odd thing about my current build script: the current optimization level is -O2. I can't use -O0, this causes an assertion failure in the lowering pass for LLVM intrinsics. The problem has to do with inlining and llvm.gcroot(). My frontend insures that all calls...

...am not 100% > sure to have updated correctly the LiveInterval information. > > In terms of registers, the Femto target is simplistic : a single register > class GR16, for data and pointers, all i16. It has 16 registers, R0 to R15; > R15 is used as stack pointer, and R14 potentialy as framepointer. A pair is > constituted from a register + its successor, i.e. (R0, R1), (R1,R2), (R2, R3), > ... are valid pairs. This is an instruction encoding constraint, as we only > have 16bits wide instructions. Pairs involving R15 are never allowed, those > with R14 may be allowed, depending on...

...e IsFrameIndex isn't getting set for the first > instruction there. yes, this needs to be added for each target. for our target i've modified the loadRegFromStackSlot and storeRegToStackSlot methods to add information on the frame index: BuildMI(MB, MBI, TII.get(STORE_REG_IMM)).addReg(framePointer) .addFrameIndex(FrameIndex).addReg(SrcReg).addSVOp(FrameIndex); > I'm curious why you added a new node kind, TargetSrcValue, instead of just > using the existing SRCVALUE. this is needed to ensure that the lowering pass does not rewrite them. i don't know if this is actually...

...rectly the LiveInterval > > information. > > > > In terms of registers, the Femto target is simplistic : a single > > register > > class GR16, for data and pointers, all i16. It has 16 registers, R0 to > > R15; R15 is used as stack pointer, and R14 potentialy as framepointer. > > A pair is constituted from a register + its successor, i.e. (R0, R1), > > (R1,R2), (R2, R3), ... are valid pairs. This is an instruction encoding > > constraint, as we only have 16bits wide instructions. Pairs involving > > R15 are never allowed, those with R14 may be a...

...; > > > > In terms of registers, the Femto target is simplistic : a single > > > register > > > class GR16, for data and pointers, all i16. It has 16 registers, R0 > > > to > > > R15; R15 is used as stack pointer, and R14 potentialy as > > > framepointer. > > > A pair is constituted from a register + its successor, i.e. (R0, > > > R1), > > > (R1,R2), (R2, R3), ... are valid pairs. This is an instruction > > > encoding > > > constraint, as we only have 16bits wide instructions. Pairs > > > involv...

...> > information. > > > > > > In terms of registers, the Femto target is simplistic : a single > > > register > > > class GR16, for data and pointers, all i16. It has 16 registers, R0 to > > > R15; R15 is used as stack pointer, and R14 potentialy as framepointer. > > > A pair is constituted from a register + its successor, i.e. (R0, R1), > > > (R1,R2), (R2, R3), ... are valid pairs. This is an instruction encoding > > > constraint, as we only have 16bits wide instructions. Pairs involving > > > R15 are never allowed, tho...

...I asked a gdb developer about it two summers ago when I was working on this, but he seemed dismissive about teaching gdb how to get this right. Reid On Fri, Oct 15, 2010 at 8:58 PM, Yuri <yuri at rawbw.com> wrote: > I run some code in JIT on x86-64 architecture. > Even though llvm::NoFramePointerElim is set to true, I still see weird > stack in gdb, see below. > 800b485a4 is the current rip register where gdb stopped. Then many > others values aren't valid. Then there is value that looks ok again. > > Why gdb can't determine stack? > > Yuri > > > -- sta...

On Oct 20, 2010, at 10:49 PM, Talin wrote: > First, there are a bunch of .bc files that are generated by my frontend, and which contain debugging metadata (I checked using llvm-dis and the metadata appears to be OK). These are then combined by my linker, tartln, which combines the functions of 'opt' and 'llc', as well as having some custom passes for reflection and garbage

...>>> In terms of registers, the Femto target is simplistic : a single >>>> register >>>> class GR16, for data and pointers, all i16. It has 16 registers, R0 >>>> to >>>> R15; R15 is used as stack pointer, and R14 potentialy as >>>> framepointer. >>>> A pair is constituted from a register + its successor, i.e. (R0, >>>> R1), >>>> (R1,R2), (R2, R3), ... are valid pairs. This is an instruction >>>> encoding >>>> constraint, as we only have 16bits wide instructions. Pairs >>&gt...

On Mon, Jul 23, 2007 at 02:19:38PM +0200, Florian Brandner wrote: > hi, > > i know it took a while, but here is a patch that adds a list of source > values to machine instructions. Cool! > i've testet all this for our backend only, which is not public. i do not > know how much has to be done to integrate this with the other, e.g., the > x86, targets. does any of the

Hi Arnaud, LiveInterval::markNotSpillable() sets the live interval's spill weight to infinity. For well-formed PBQP graphs (i.e. ones that have some finite-cost solution), PBQP should never chose to spill such an interval. The two possibilities for this crash are that the input graph has no finite-cost solution, or that you've exposed a bug in the PBQP solver. >From memory your target

...registers, the Femto target is simplistic : a single > >>>> register > >>>> class GR16, for data and pointers, all i16. It has 16 registers, R0 > >>>> to > >>>> R15; R15 is used as stack pointer, and R14 potentialy as > >>>> framepointer. > >>>> A pair is constituted from a register + its successor, i.e. (R0, > >>>> R1), > >>>> (R1,R2), (R2, R3), ... are valid pairs. This is an instruction > >>>> encoding > >>>> constraint, as we only have 16bits wide instru...

Hi All, I finally had a chance to get back to my pbqp trials, now using the 3.0 release. I still hit the same assert : "Attempting to spill already spilled value." This is triggered because in RegAllocPBQP::mapPBQPToRegAlloc, a vreg node is either : - a physical register (problem.isPRegOption(vreg, alloc)), - or a spill (problem.isSpillOption(vreg, alloc)) The problem is that pass

Another chapter in the long saga of trying to get source-level debugging working :) I've switched over to using the direct object-file generation instead of generating assembly in hopes of getting around the "Fatal error: duplicate .debug_line sections" binutils bug. I now have 4 different tools for dumping the DWARF info for an object module: dwarfdump, objdump, readelf, and

I run some code in JIT on x86-64 architecture. Even though llvm::NoFramePointerElim is set to true, I still see weird stack in gdb, see below. 800b485a4 is the current rip register where gdb stopped. Then many others values aren't valid. Then there is value that looks ok again. Why gdb can't determine stack? Yuri -- stack -- #0 0x0000000800b485a4 in ?? () #1 0x...

hi, i know it took a while, but here is a patch that adds a list of source values to machine instructions. i modified the DAGISelEmiter to automatically catch regular loads/stores. custom instructions and loads/stores rewritten by the lowering pass are not automatically captured. during the instruction selection a source value operand is added to the DAG for patterns matching a load/store.

Hi! I'm making a strange observation in my backend, that ends in illegal code: Version 1: - I lower FrameIndex to TargetFrameIndex (nothing special) - I generate a special address-register ADD instruction in eliminateFrameIndex() to write FramePointer + offset into a new address-register - I use explicit load and store and address-registers in my target instruction patterns: eg (store (add (load AddressRegs:$a), DataRegs:$b), AddressRegs:$dst) This works quite well, but if I access an array on the stack (LLVM generates FrameIndex to access i...

Hello, Arnold. > with the sentence i tried to express the question whether there is a > way to persuade the code generator to use another register to load (or > move) the function pointer to (right before the callee saved register > restore) but thinking a little further that's nonsense. Why don't define some special op for callee address and custom lower it? I really

On Tue, Jun 26, 2018 at 1:28 PM Adrian Prantl <aprantl at apple.com> wrote: > > > > On Jun 26, 2018, at 11:58 AM, Zachary Turner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hi all, > > > > We have been thinking internally about a lightweight llvm-based > ptracer. To address one question up front: the primary way in which this