similar to: [LLVMdev] Converting a Constant GEP to a POD integer?

Hi Talin, > This is all happening at link time, which means that the target machine is fully > known by this point. So it ought to be possible to convert the field offset > expression (including the constant GEP) into a plain integer. Any idea how to do > this? probably you can just run the constant folder on it (passing the target data to the constant folder). Ciao, Duncan.

Here's a sketch of what I am proposing for ConstantBuilder. I'd like feedback on naming conventions, doc comments, etc. //===-- llvm/Support/ConstantBuilder.h - Builder for Constants --*- C++ -*-===// // // The LLVM Compiler Infrastructure // // This file is distributed under the University of Illinois Open Source // License. See LICENSE.TXT for details. //

On Sep 22, 2009, at 4:49 PM, Talin wrote: > > // Calculate the size of the specified LLVM type. > Constant * DebugInfoBuilder::getSize(const Type * type) { > Constant * one = ConstantInt::get(Type::Int32Ty, 1); > return ConstantExpr::getPtrToInt( > ConstantExpr::getGetElementPtr( > ConstantPointerNull::get(PointerType::getUnqual(type)), >

On Wed, Sep 23, 2009 at 1:51 PM, Dan Gohman <gohman at apple.com> wrote: > > On Sep 22, 2009, at 4:49 PM, Talin wrote: > >> >> // Calculate the size of the specified LLVM type. >> Constant * DebugInfoBuilder::getSize(const Type * type) { >> Constant * one = ConstantInt::get(Type::Int32Ty, 1); >> return ConstantExpr::getPtrToInt( >>

On Wed, Sep 23, 2009 at 2:27 PM, Talin <viridia at gmail.com> wrote: > On Wed, Sep 23, 2009 at 1:51 PM, Dan Gohman <gohman at apple.com> wrote: >> >> On Sep 22, 2009, at 4:49 PM, Talin wrote: >>> >>> // Calculate the size of the specified LLVM type. >>> Constant * DebugInfoBuilder::getSize(const Type * type) { >>>    Constant * one =

Here is a patch that does just that. On Wed, Sep 23, 2009 at 3:38 PM, Devang Patel <devang.patel at gmail.com>wrote: > On Wed, Sep 23, 2009 at 2:27 PM, Talin <viridia at gmail.com> wrote: > > On Wed, Sep 23, 2009 at 1:51 PM, Dan Gohman <gohman at apple.com> wrote: > >> > >> On Sep 22, 2009, at 4:49 PM, Talin wrote: > >>> > >>>

On Tue, Sep 22, 2009 at 9:21 AM, Devang Patel <devang.patel at gmail.com> wrote: > On Tue, Sep 22, 2009 at 12:14 AM, Talin <viridia at gmail.com> wrote: >> So, one feature of the late, lamented DebugInfoBuilder that I am missing >> quite badly, and which is not available in the current DIFactory, is the >> ability to specify structure offsets abstractly. The

On Tue, Sep 22, 2009 at 9:21 AM, Devang Patel <devang.patel at gmail.com>wrote: > On Tue, Sep 22, 2009 at 9:21 AM, Devang Patel <devang.patel at gmail.com> > wrote: > > On Tue, Sep 22, 2009 at 12:14 AM, Talin <viridia at gmail.com> wrote: > >> So, one feature of the late, lamented DebugInfoBuilder that I am missing > >> quite badly, and which is not

On Mon, Mar 7, 2011 at 4:08 AM, nicolas geoffray <nicolas.geoffray at gmail.com > wrote: > Hi Talin, > > On Sat, Mar 5, 2011 at 6:42 PM, Talin <viridia at gmail.com> wrote: >> >> >> So I've been thinking about your proposal, that of using a special address >> space to indicate garbage collection roots instead of intrinsics. > > > Great!

*Motivation & Abstract* It has been observed by a number of LLVM users that the current garbage collection framework requires frontends to generate complex and inefficient code. This is primarily due to the fact that only allocas can be stack roots - it is not possible to trace SSA values directly. Because of this limitation, a frontend wanting to support garbage collection has to manually

On Mon, Mar 7, 2011 at 9:35 AM, Talin <viridia at gmail.com> wrote: > On Mon, Mar 7, 2011 at 4:08 AM, nicolas geoffray < > nicolas.geoffray at gmail.com> wrote: > >> Hi Talin, >> >> On Sat, Mar 5, 2011 at 6:42 PM, Talin <viridia at gmail.com> wrote: >>> >>> >>> So I've been thinking about your proposal, that of using a

Looking at DebugInfo.h, there are a couple of minor features that DebugInfoBuilder that I would miss: 1) The ability to pass in an LLVM type and have it figure out the size, alignment, etc. without having to explicitly pass those values in as parameters to the builder call. 2) The ability for the size & alignment to be specified as Constants rather than as int64 so that the "gep

On Wed, Feb 2, 2011 at 1:29 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > Talin wrote: > >> On Mon, Jan 31, 2011 at 10:57 PM, Talin <viridia at gmail.com >> <mailto:viridia at gmail.com>> wrote: >> >> I notice that there's a lot of inconsistency in the various LLVM >> classes with respect to convenience methods. Here's some

Forgive my top post but I hate Windows. J I am surprised you (Talin) say that "we know conservative collectors work" because my experience has very much been of them not working. Indeed, if you have 400Mb of allocated heap blocks on a 32-bit machine is there not a 10% chance of *each* random 32-bit int "pointing" into your heap, i.e. a false positive? I just did a simple

DebugInfo.h is very light weight interface that allows one to manipulate llvm values that holds debugging information directly. On Jan 7, 2009, at 3:22 PM, Talin wrote: > Looking at DebugInfo.h, there are a couple of minor features that > DebugInfoBuilder that I would miss: > > 1) The ability to pass in an LLVM type and have it figure out the > size, alignment, etc. without

On Jul 26, 2011, at 8:11 AM, Talin wrote: >> >> If that's true, then it means that we're back to the case where every type has to be fully defined down to the leaf level. > > I'm not sure what you mean. LLVM is perfectly fine with opaque structs so long as you don't "deference" them, GEP into them, need their size, etc. > > Let me try with

More questions on the best way to write a compiler using LLVM: Lets say I have a struct definition that looks like this: const int imageSize = 77; struct A { char B[align(imageSize)]; } ...where 'imageSize' is some small inline function that rounds up to a power of two or something. (A common requirement for textures on 3d graphics cards.) Now, clearly the compiler

On Wed, Sep 22, 2010 at 5:58 AM, Kenneth Uildriks <kennethuil at gmail.com>wrote: > On Tue, Sep 21, 2010 at 8:20 PM, Talin <viridia at gmail.com> wrote: > > On Mon, Sep 20, 2010 at 3:16 PM, Talin <viridia at gmail.com> wrote: > >> > >> So I've managed to get my stack crawler working and passing its unit > tests > >> - this is the one

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

Gordon Henriksen wrote: > On 2007-09-15, at 23:55, Talin wrote: > >> Gordon Henriksen wrote: >> >>> Can you be more specific the algorithm for which you need type >>> metadata in a write barrier? No algorithms I am aware of perform any >>> tracing from a write barrier. >> >> This one does: >> >>