similar to: [LLVMdev] Class or instance?

Thanks for the fast reply. I'll do as you suggested, and create my own identity instructions with "add" for int's and "getelementptr" for pointers. , Tobias On Thu, 17 Jun 2004, Misha Brukman wrote: > On Thu, Jun 17, 2004 at 05:09:30PM +0200, Tobias Nurmiranta wrote: > > A small thing I miss in the intermediate representation is a simple > > assignment

Hi again, Which optimization/flag to "opt" should I use to optimize away these alloca's? In most cases it is more convenient for me to use SSA-registers, but for example if-statements and some others, it is nicer to use alloca. Thanks for the advice. , Tobias On Thu, 17 Jun 2004, Chris Lattner wrote: > On Thu, 17 Jun 2004, Tobias Nurmiranta wrote: > > > > Thanks for

On Thu, 22 Jul 2004, Chris Lattner wrote: > On Thu, 22 Jul 2004, Tobias Nurmiranta wrote: > > Hmm, it felt nicer to mark raw LLVM pointers as roots and then transform > > them, since I then didn't have to see the overhead in my frontend :). > > I'm not sure what overhead you mean. I think I should have emphasized "felt", since it only would make me produce

On Mon, 19 Jul 2004, Tobias Nurmiranta wrote: > Regarding llvm.gcroot, do I have to allocate stack-space for all > pointers in a function? Right now I mostly use SSA-variables, and let > llvm's register allocation allocate stack-space when needed. Yes. This reflects the fact that the GC can move objects (to compact the heap) at unpredictable times. > Also, what happens when I

Hi. A small thing I miss in the intermediate representation is a simple assignment instruction, like: %x = uint 3 or: %x = uint %y It would simplify the implementation of frontends, I think. , Tobias

On Thu, 17 Jun 2004, Tobias Nurmiranta wrote: > > Thanks for the fast reply. I'll do as you suggested, and create my own > identity instructions with "add" for int's and "getelementptr" for > pointers. Another thing to point out is that this might only be happening because your front-end is attempting to generate SSA. In general, we don't recommend

On Thu, 22 Jul 2004, Chris Lattner wrote: > > While I was editing LowerGC.cpp I made a little test (not part of this > > patch, but the diff with LowerGC.cpp in cvs is attached). I've added a new > > intrinsic called llvm.gcroot_value(sbyte*, sbyte*), which takes a pointer > > directly instead and transforms it into an alloca. The idea is the > ... > > In this

On Mon, 19 Jul 2004, Tobias Nurmiranta wrote: > > Not currently. In the future this will definitely be improved. In > > particular, when the code generators are enhanced to provide more accurate > > mapping information for GC pointers (e.g. which registers contain > > pointers), we can do this. This is in the long term plans, but I suspect > > that performance will

On Sat, 17 Jul 2004, Chris Lattner wrote: > > http://www.ida.liu.se/~tobnu/scheme2llvm/ > > Looks great! > > > (what's a blurb? :) > > Just a summary, so that I can add an entry to this page: > http://llvm.cs.uiuc.edu/ProjectsWithLLVM/ Maybe this for now: "This is a small self applicable scheme compiler for LLVM. The code is quite similar to the code in

On Mon, 19 Jul 2004, Chris Lattner wrote: > On Mon, 19 Jul 2004, Tobias Nurmiranta wrote: > > > Regarding llvm.gcroot, do I have to allocate stack-space for all > > pointers in a function? Right now I mostly use SSA-variables, and let > > llvm's register allocation allocate stack-space when needed. > > Yes. This reflects the fact that the GC can move objects (to

On Thu, Jun 17, 2004 at 05:09:30PM +0200, Tobias Nurmiranta wrote: > A small thing I miss in the intermediate representation is a simple > assignment instruction, like: > > %x = uint 3 > or: > %x = uint %y > > It would simplify the implementation of frontends, I think. Neither of these is necessary, and adding new instructions means every transformation has to handle

On Thu, 22 Jul 2004, Tobias Nurmiranta wrote: > > Unfortunately this won't really work. It might be reasonable to include > > something like this in the front-end that you're working on, but including > > this at the LLVM level is a bad idea. The basic idea of the alloca model > > is that it directly exposes to the optimizer the fact that GC pointers may > >

Hi, I am a newbie to LARTC and to this mailing-list. I have read through the Linux Advanced Routing & Traffic Control HOWTO many times, trying to understand Classful Queueing Disciplines (and in particular CBQ). I have some suggestions that I think will help to make the HOWTO more understandable. Suggestions ========= (1) In section 9.4 (Terminology) the definition for

On Wed, 18 Aug 2004, Reid Spencer wrote: > On Wed, 2004-08-18 at 11:54, Tobias Nurmiranta wrote: > > Okay. I'm not an expert on GC but I'll take a look ... Thanks :) > > > For some strange reason I get segmentation fault in process_pointer in > > semispace.c (I've implemented a small collector, hopefully :). The fault > > occurs when I do: > > >

Hi, I need to find out all the places where the value of a variable is being used. For this I have to implement reaching definitions(def-use chains). When I searched for its implementation I found Iterating over def-use & use-def chains <http://llvm.org/docs/ProgrammersManual.html#iterate_chains>. will this work for finding the places where a variable is reaching? I tried to use

Nia, I improved the documentation with this patch: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of- Mon-20060410/034012.html You can read it online, here: http://llvm.org/docs/ProgrammersManual.html#GlobalVariable Please let me if you need further explanation in the documentation. Reid. On Fri, 2006-04-14 at 18:19 +0800, Nai Xia wrote: > Hi, > I apologize if it is a rather stupid

Hi Duncan Sands, I frankly don't know what a variable gets converted to (SSA register or memory chunk). What I meant is, for example I1: int i, j=10; I2: scanf("%d", &j); I3: i = j + 1; Here I want to know whether the value of j in I1 reaches I3 or not. Best Regards, Srikanth Vaindam you didn't define what you mean by a variable. LLVM has virtual registers which are

Hi, Regarding llvm.gcroot, do I have to allocate stack-space for all pointers in a function? Right now I mostly use SSA-variables, and let llvm's register allocation allocate stack-space when needed. Also, what happens when I run the mem2reg pass, does it handle llvm.gcroot's that are moved from stack to registers? I'm thinking along the lines, that should one not use llvm.gcroot on

On 11 June 2017 at 23:06, Jeremy Lakeman <Jeremy.Lakeman at gmail.com> wrote: > http://llvm.org/docs/ProgrammersManual.html#the-isa-cast-and-dyn-cast- > templates > I understand isa and dyn-cast let you test the type of an object at run-time by leveraging LLVM's custom implementation of RTTI. However, it doesn't make much sense to test out for all possible sub-classes to

On Nov 13, 2020, at 2:06 PM, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote: > We've pretty happy now with a patch that adds two wrappers around SmallVector that make it 1) more convenient to use and 2) will tend to mitigate misuse of SmallVector. We think it's ready for wider discussion: https://reviews.llvm.org/D90884 <https://reviews.llvm.org/D90884> >