similar to: [LLVMdev] Register variables

On Wed, 20 Jun 2007, Sandro Magi wrote: > To this end, are there any implicit allocations being done by > generated LLVM code, other than the system stack? heap allocations? Only malloc/free. Note that the compiler does generate calls to runtime libraries (e.g. libstdc++ and libgcc), we don't have control over when they do allocations. The libstdc++ calls show up in the .ll file,

On Sun, 8 Jul 2007, Sandro Magi wrote: > How about if I were to use LLVM's JIT? I suspect plenty of allocations > are performed in the JIT. The JIT does a ton of heap allocation. There is no way to approximate it from the code you give it. -Chris > Sandro > > On 6/20/07, Chris Lattner <sabre at nondot.org> wrote: >> On Wed, 20 Jun 2007, Sandro Magi wrote:

Hi, Teresa, This looks really useful. It seems like this general infrastructure could be useful for diagnosing places where we have a lot of false sharing too. This could be between cores, sockets, or devices. Looking forward, especially with HMM and support under Linux for transparent unified memory between CPUs and accelerators, I anticipate we'll end up looking for places where some

On Wed, Jul 8, 2020 at 6:30 PM Kostya Serebryany <kcc at google.com> wrote: > > > On Wed, Jun 24, 2020 at 4:58 PM Teresa Johnson <tejohnson at google.com> > wrote: > >> Hi all, >> >> I've included an RFC for a heap profiler design I've been working on in >> conjunction with David Li. Please send any questions or feedback. For >>

On Sat, Jul 4, 2020 at 11:28 PM Wenlei He <wenlei at fb.com> wrote: > This sounds very useful. We’ve improved and used memoro > <https://www.youtube.com/watch?v=fm47XsATelI> for memory profiling and > analysis, and we are also looking for ways to leverage memory profile for > PGO/FDO. I think having a common profiling infrastructure for analysis > tooling as well as

On Wed, May 15, 2013 at 9:46 PM, Chris Lattner <clattner at apple.com> wrote: > It's not clear to me that "builtin" is the right way to model this, but it > definitely sounds like this should be an attribute on a call site (as > opposed to on the function itself). What specific kinds of optimizations > are we interested in doing to _Znwm calls? You can see the

On Aug 8, 2010, at 9:20 PM, Reid Kleckner wrote: > I thought I dug into the register allocation code, and found the > VNInfo::Allocator typedef. I assumed that was getting the traffic we > saw in Instruments, but I don't have the data to back that up. Are you using llvm from trunk? VNInfo is a lot smaller now than it was in 2.7. I would guess about a third of the liveness memory

On 7/10/07, Chris Lattner <sabre at nondot.org> wrote: > On Sun, 8 Jul 2007, Sandro Magi wrote: > > How about if I were to use LLVM's JIT? I suspect plenty of allocations > > are performed in the JIT. > > The JIT does a ton of heap allocation. There is no way to approximate it > from the code you give it. I don't need to approximate it, but I'd like to

Hi all, I've included an RFC for a heap profiler design I've been working on in conjunction with David Li. Please send any questions or feedback. For sanitizer folks, one area of feedback is on refactoring some of the *ASAN shadow setup code (see the Shadow Memory section). Thanks, Teresa RFC: Sanitizer-based Heap Profiler Summary This document provides an overview of an LLVM

This isn't a strictly llvm-related problem, but I thought I'd ask anyway to see if anyone can help. I'm trying to write a dynamically typed language on top of llvm. My initial idea was to have a general object type for all objects in my language. I came up with: { i8, i8* } the first element of the structure would hold the type of the object, and the second is a pointer to the

On 8 July 2011 00:07, Kenneth Uildriks <kennethuil at gmail.com> wrote: > You don't need function parameters to be stack roots.  You already > have a stack root for those values in the calling function, right? Allowing parameters themselves to be stack roots allows an object that the calling function itself no longer needs to be collected once the called function (and everyone

> Wouldn't a thread-local global variable solve your problem? > > Best regards, > --Edwin Are thread-local variables supported on all platforms? If so, than probably yes... both the pointers would probably be kept in the processor cache, which would speed-wise probably be comparable (will it be?) with keeping variables in the registers. - Tom Primožič -------------- next part

How about if I were to use LLVM's JIT? I suspect plenty of allocations are performed in the JIT. Sandro On 6/20/07, Chris Lattner <sabre at nondot.org> wrote: > On Wed, 20 Jun 2007, Sandro Magi wrote: > > To this end, are there any implicit allocations being done by > > generated LLVM code, other than the system stack? > > heap allocations? Only malloc/free. Note

On Tue, 10 Jul 2007, Sandro Magi wrote: > On 7/10/07, Chris Lattner <sabre at nondot.org> wrote: >> On Sun, 8 Jul 2007, Sandro Magi wrote: >>> How about if I were to use LLVM's JIT? I suspect plenty of allocations >>> are performed in the JIT. >> The JIT does a ton of heap allocation. There is no way to approximate it >> from the code you give it.

On Sun, Aug 8, 2010 at 8:20 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Aug 7, 2010, at 7:05 PM, Steven Noonan wrote: >> I've been doing work on memory reduction in Unladen Swallow, and >> during testing, LiveRanges seemed to be consuming one of the largest >> chunks of memory. > > That's interesting. How did you measure this? I'd

To this end, are there any implicit allocations being done by generated LLVM code, other than the system stack? Sandro On 6/18/07, Sandro Magi <naasking at gmail.com> wrote: > Given my recent posts, I think it's obvious that I'm trying to figure > out how to build a resource-aware VM for a high-level language. > > I've figured out adequate solutions for most of the

On Mon, 9 Aug 2010 09:36:53 -0700 Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Aug 8, 2010, at 9:20 PM, Reid Kleckner wrote: > > > I thought I dug into the register allocation code, and found the > > VNInfo::Allocator typedef. I assumed that was getting the traffic > > we saw in Instruments, but I don't have the data to back that up. > >

On Wed, Jul 6, 2011 at 9:21 PM, Talin <viridia at gmail.com> wrote: > That's an interesting suggestion. > I realized, however, that there's another advantage to using type-based > marking rather than an intrinsic - it allows you to declare function > parameters as stack roots. Depending on the calling convention, some of the > parameters to a function will be located

Given my recent posts, I think it's obvious that I'm trying to figure out how to build a resource-aware VM for a high-level language. I've figured out adequate solutions for most of the problems I've encountered, including separate heaps, quotas, etc. However, I'm not sure how I can account for a thread's stack space. Given a language process (LP) running in a heap with a

2010/8/9 Török Edwin <edwintorok at gmail.com>: > On Mon, 9 Aug 2010 10:17:27 -0700 > Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > >> >> On Aug 9, 2010, at 9:54 AM, Török Edwin wrote: >> >> > With mmap() it is always possible to fully release the memory once >> > you are done using it. >> >> Sure. Is that the goal, though?