search for: magie

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:

-------- Original Message -------- Subject: rsync seem to be broken on sparc64 Date: 2016-06-27 23:43 From: alexmcwhirter at triadic.us To: debian-sparc at lists.debian.org I posted about this in the kernel lists a few months ago to no avail. I see it on gentoo as well with any kernel newer than 3.18. I came across this when using lxc on sparc64. The debian template uses rsync to move the

.... My public share in smb.conf is: [publica] available = yes browseable = yes comment = public folder guest ok = yes path = /home/public read only = no writable = yes The problem is: The user Bob open any folder located in publica share, then create a new folder and insert new content. The user Magie open the folder created by Bob and your content is invisible for Magie and others users. Only Bob can view the contents!!! Help me please! ThanX!

Ok, so if I needed very precise control over the allocation of memory, then I should avoid using integers with bit widths larger than 64 bits (or perhaps 128)? Is there a hard rule for an integer being stack allocated, ie. one that doesn't depend on the current implementation details? Sandro On 6/18/07, Reid Spencer <rspencer at reidspencer.com> wrote: > Sandro Magi wrote: > >

I'm having trouble achieving the results I want using a regular expression. I want to eliminate all characters that fall within square brackets as well as the brackets themselves, returning an "". I'm not sure if it's R's use of double slash escapes or something else that is tripping me up. If I only use one slash I get 1: '\[' is an unrecognized escape in a

On 6/18/07, Chris Lattner <sabre at nondot.org> wrote: > On Mon, 18 Jun 2007, Sandro Magi wrote: > > Ok, so if I needed very precise control over the allocation of memory, > > then I should avoid using integers with bit widths larger than 64 bits > > (or perhaps 128)? Is there a hard rule for an integer being stack > > allocated, ie. one that doesn't depend on

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 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

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.

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, 18 Jun 2007, Sandro Magi wrote: > Ok, so if I needed very precise control over the allocation of memory, > then I should avoid using integers with bit widths larger than 64 bits > (or perhaps 128)? Is there a hard rule for an integer being stack > allocated, ie. one that doesn't depend on the current implementation > details? In the generated code, or in the compiler

Where does the storage for large bit width integers come from? Are very large numbers heap allocated? Sandro

Sorry, clicked send by accident. It seems there's some background I'm missing though. Can I read up on this "as-if" rule anywhere? I was just saying this translation seems safe for word-sized or smaller objects, since those could end up being allocated to registers and such. My confusion is over larger object sizes. At what point would the translation not be done, or would it

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

I know almost nothing about modern SPARC64 systems especially when they are running linux. But, can you try this command line and see if it gives more information before it blows up: rsync -vvai /export/test/ /export/test2/ On 06/28/2016 05:39 PM, alexmcwhirter at triadic.us wrote: > -------- Original Message -------- > Subject: rsync seem to be broken on sparc64 > Date: 2016-06-27

On Thu, 1 May 2008, Sandro Magi wrote: >> If LLVM is able to eliminate all users of the malloc assuming the >> malloc succeeded (as in this case), then it is safe to assume the malloc >> returned success. > > I don't see how this could be true in general, without either > knowledge of the malloc implementation, which would be fine, or > presuming knowledge of

On Tue, 14 Mar 2006, Sandro Magi wrote: >> consider all pointers to be in scope, without causing any "dead" pointers >> to mark objects. > > Does this mean some pointers from the roots might be null? Well sure, if they are null. e.g.: int *X = NULL; X would be null. Is that what you mean? > I figured > only in-scope variables/roots would be in the

On Mon, 18 Jun 2007, Sandro Magi wrote: > Generated code. So the memory used for the integer at program runtime > is inlined into the allocation point then? So if I define a local > variable of type 'i1024', it will allocate a block of 1024 bits on the > stack, if I define a struct with an i1024, it will be in the struct > itself, etc. Yes, exactly. > Is there anyone

On 9/28/07, Chris Lattner <sabre at nondot.org> wrote: > > > Sorry, I meant to ask whether it's still necessary to keep F around, > > ie. to delete generated code. Is there a standard approach to garbage > > collecting code in LLVM? > > Machine code in the JIT buffer or the LLVM IR itself? > Assuming I don't need to keep around the IR version of a