search for: framepointers

Hi Lang, > From memory your target is not public, so I won't be able to reproduce > the crash myself. Is that correct? Correct. > If that's the case, I could add functionality to dump the PBQP graphs > during allocation. I think they should give me enough information to > debug the issue. Would you be able to share the PBQP graphs? I can share the pbqp graph if you send

On Thu, Oct 21, 2010 at 8:56 AM, Devang Patel <dpatel at apple.com> wrote: > > 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,

Hi Arnaud, Thanks for attaching those files. I'll take a look at them. Commit r153483 adds an option to the PBQP allocator, "-pbqp-dump-graphs", to dump the PBQP graph for each round of each function in a compilation unit. The generated files are named "<module id>.<function>.<round>.pbqpgraph", and contain a simple text representation of the PBQP graph.

Dan Gohman wrote: > I tried out your patch on x86 and it didn't appear to need any special changes. it might be needed to look at the addressing modes of a load/store to get the right offset. but i think it should work, if the lowering does not rewrite loads/stores into custom DAG nodes. > For the [??], it looks like the IsFrameIndex isn't getting set for the first > instruction

Hi Lang, I have reduced the testcase as much as possible. The log of the run and the dumped graphes are attached. Cheers, -- Arnaud de Grandmaison On Tuesday, March 27, 2012 01:20:35 Lang Hames wrote: > Hi Arnaud, > > Thanks for attaching those files. I'll take a look at them. > > Commit r153483 adds an option to the PBQP allocator, > "-pbqp-dump-graphs", to

Hi Lang, Thanks a lot for taking time to look into this. I will test the fix soon and let you know the results. Cheers, -- Arnaud de Grandmaison On Tuesday, April 03, 2012 17:30:33 Lang Hames wrote: > Hi Arnaud, > > Apologies for the delayed reply. > > Thank you for the excellent test case - it exposed a subtle bug in the > colorability heuristic. This has been fixed in

Hi Arnaud, Apologies for the delayed reply. Thank you for the excellent test case - it exposed a subtle bug in the colorability heuristic. This has been fixed in r153958. In case you are curious, the bug was as follows: the PBQP solver applies applies a simplification step to each matrix. When all elements of a matrix row or column are equal, the value for those elements is "pushed

I know you haven't been able to get the JIT gdb support to work on FreeBSD (right?), but this is exactly the problem that we ran into that it solves. http://llvm.org/docs/DebuggingJITedCode.html I don't know what heuristic gdb is trying to use to unwind the stack, but it doesn't work. I asked a gdb developer about it two summers ago when I was working on this, but he seemed

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

Hi Lang, The assert is not triggered any longer on my testcases :) I however still get my wrong allocation in some non trivial cases : the pairing constraint is not fulfilled. I have tried to modify the 'ensure pairable' pass (the pass undoing some of the coalescer's work) to always insert register copies for instructions with the pairable constraint, instead of being smart and

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

Hi Arnaud, I'm glad to hear that your test case is working. I however still get my wrong allocation in some non trivial cases : the > pairing constraint is not fulfilled. > > I have tried to modify the 'ensure pairable' pass (the pass undoing some > of the coalescer's work) to always insert register copies for > instructions with the pairable constraint, instead of

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 0x000000000000005f in

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

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