similar to: [LLVMdev] Stuck

On Sun, Feb 28, 2010 at 9:55 AM, Gordon Henriksen <gordonhenriksen at me.com> wrote: > In practice, so long as frame pointers are not elided, a handful of lines of > assembly per platform should get you a stack walker. If frame pointers are > elided, however, you're looking at parsing DWARF to find out where it was > saved, which is probably too expensive for the job. Unless

On Mon, Apr 28, 2008 at 8:31 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > On 2008-04-28, at 21:19, Lane Schwartz wrote: > > > On Mon, Apr 28, 2008 at 2:13 PM, Gordon Henriksen <gordonhenriksen at mac.com > > > wrote: > > > >>> If so, then a Collector plugin would need to have info about every > >>> supported backend

On Mon, Apr 28, 2008 at 2:13 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > > If so, then a Collector plugin would need to have info about every > > supported backend lays out the runtime stack? > > Yes. This information is actually available in a target-independent > fashion with LLVM, so the Collector interface is target-independent. A > backend

2008/7/26 Gordon Henriksen <gordonhenriksen at me.com>: > I'm not sure the purpose of doing so—llvm::Collector (poorly named; > I'm open to suggestions) exists only in the compiler, not at runtime > in the compiled program. You should need access to it at runtime no > more than you might need access to an instance of llvm::TargetMachine. Maybe I don't understand the

On 2008-04-28, at 21:19, Lane Schwartz wrote: > On Mon, Apr 28, 2008 at 2:13 PM, Gordon Henriksen <gordonhenriksen at mac.com > > wrote: > >>> If so, then a Collector plugin would need to have info about every >>> supported backend lays out the runtime stack? >> >> Yes. This information is actually available in a target-independent >>

On Sep 2, 2007 5:31 AM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > Hi Talin, > > On Sep 2, 2007, at 04:54, Talin wrote: > > > I've been looking through the documentation (http://llvm.org/docs/ > > GarbageCollection.html) on how to implement a garbage collector for > > LLVM and there's a couple of things that I don't quite understand. >

On Jul 26, 2008, at 12:14, Simon Ask Ulsnes wrote: > 2008/7/26 Gordon Henriksen <gordonhenriksen at me.com>: >> I'm not sure the purpose of doing so—llvm::Collector (poorly named; >> I'm open to suggestions) exists only in the compiler, not at >> runtime in the compiled program. You should need access to it at >> runtime no more than you might need

A little while ago I asked a question on CFE-Dev about a change in the behaviour of programs using the ISO C math functions, although that question should have been put to LLVM-Dev. But I got excellent clarification of the problem anyway. However, since then I have been trying to adapt our out-of-tree implementation to get the previous behaviour. The problem is that something like: #include

Thanks for the review Gordon. On Tue, Nov 1, 2011 at 2:21 AM, Gordon Henriksen <gordonhenriksen at mac.com>wrote: > On 2011-10-31, at 17:21, Nicolas Geoffray wrote: > > > Here's a patch to allow a GCStrategy to customize the places where it > wants to insert safe points. I'm not sure who maintains the GC code today > in LLVM (I'd be happy to take ownership, if

On Sun, Apr 27, 2008 at 9:34 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > As for the compiler plugin interface, I suggest you ignore it > initially and use the provided shadow-stack option for the time being. > The shadow stack generates significantly suboptimal code, but will let > you avoid writing some platform-specific code. Instead, simply copy > the

On Nov 7, 2008, at 15:29, Scott Graham wrote: > I'm getting an assert in LowerIntrinsics::InsertRootInitializers > because I'm gcroot'ing an alloca to a non-pointer. > > I was hoping to modify InsertRootInitializers to memset the > structure in the case that it's not a pointer, but I'm not sure how > to. Can anyone suggest what should go at "todo;

On Nov 1, 2011, at 4:47 AM, Nicolas Geoffray <nicolas.geoffray at gmail.com> wrote: > Thanks for the review Gordon. > > On Tue, Nov 1, 2011 at 2:21 AM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > On 2011-10-31, at 17:21, Nicolas Geoffray wrote: > > > Here's a patch to allow a GCStrategy to customize the places where it wants to insert safe points.

Hi I'm getting an assert in LowerIntrinsics::InsertRootInitializers because I'm gcroot'ing an alloca to a non-pointer. I was hoping to modify InsertRootInitializers to memset the structure in the case that it's not a pointer, but I'm not sure how to. Can anyone suggest what should go at "todo; something here"? ... for (AllocaInst **I = Roots, **E = Roots +

http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-August/016763.html On 2008-09-05, at 22:46, Talin wrote: > Recently I started getting these warnings - thousands of them - and > I'm > not sure what I did to cause them or how to solve them: > > ld: warning llvm::MemoryBuffer::getBufferStart() const has different > visibility (1) in

Hi Talin, On Sep 2, 2007, at 04:54, Talin wrote: > I've been looking through the documentation (http://llvm.org/docs/ > GarbageCollection.html) on how to implement a garbage collector for > LLVM and there's a couple of things that I don't quite understand. > Specifically, it says that when a stack variable goes out of scope, > you're supposed to assign a

Hello I'm implementing stack copying coroutines. It's an interesting challenge. When we use setjmp/longjmp to move between stacks, we must make sure that restoring the stack doesn't blow away the current stack frame before calling longjmp. To do that, we check how big the stack we are restoring is, and use alloca to push the current stack frame beyond that. It works but when I add

Hi Mehdi, The ISO C specification does permit the math functions to modify ‘errno’, but I thought that the ‘-fno-math-errno’ option was to tell the optimiser to assume that ‘errno’ is not modified by the math functions. Explicitly providing ‘-fno-math-errno’ is not restoring the elision optimisation that was performed by LLVM v3.8, and this is really only a driver option, with ‘-fmath-errno’

Recently I started getting these warnings - thousands of them - and I'm not sure what I did to cause them or how to solve them: ld: warning llvm::MemoryBuffer::getBufferStart() const has different visibility (1) in /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and (2) in /usr/local/lib/libLLVMSupport.a(CommandLine.o) ld: warning

Pending positive confirmation in http://llvm.org/PR2886, I'd recommend that r57974 and r57976 be pulled into the 2.4 release branch and configure regenerated there. Begin forwarded message: > From: Gordon Henriksen <gordonhenriksen at mac.com> > Date: October 22, 2008 08:40:40 EDT > To: llvm-commits at cs.uiuc.edu > Subject: [llvm-commits] [llvm] r57974 -

On 2008-05-13, at 02:12, Mahadevan R wrote: >>> That's not how the object works... > > Gordon, I think I can make it work if we have the following additional > function in LLVM-C: > > LLVMModuleRef LLVMGetModule(LLVMModuleProviderRef MP) { > return wrap(unwrap(MP)->getModule()); > } Can I ask, how general is your solution? I only intended to use this