similar to: [LLVMdev] Tool support for generation of transactional code

Torvald, This is nice work. Do you have a set of applications or benchmarks that you have transactionalized at the source level? If so, have you reported performance numbers for them somewhere? Thanks, --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.org On Aug 19, 2007, at 3:22 PM, Torvald Riegel wrote: > I would like to announce the availability of compiler support for >

First of all, I'd like to thank the entire LLVM team for this opportunity. Torvald, google only displays the abstract on the results page, but I do know about Tanger and it was mentioned in both the proposal and the comments that followed, I'll write an email to you later with that info in a bit, and I do intend to use as much available infrastructure as possible, and tanger/tinystm are

On Tuesday 22 April 2008, Chris Lattner wrote: > [llvmir] "Software Transactional Memory (STM) support in LLVM" by > Luis Felipe Strano Hi, I'd like to know more about the directions for the STM project. Somewhat contrary to what the project's abstract states, there are open C/C++ based implementations for compiler support for memory transactions. Besides some

I'm happy to say that LLVM has 6 projects approved for Google SoC this year (3x more than last year!): [vmkit] "Generics support for N3" by Tilmann Schelle [clang] "Adding support for C++ classes in clang" by Argiris Kirtzidis [codegen] "PSP (Playstation Portable) support into LLVM Mips backend" by Bruno Cardoso Lopes [llvmir]

On Sat, Apr 19, 2008 at 3:44 PM, Chris Lattner <sabre at nondot.org> wrote: > It sounds like you're doing something STM like, have you contacted > Torvald to see if he has ideas or insight? > http://llvm.org/pubs/2008-02-23-TRANSACT-TangerObjBased.html Yeah, this is TM-like with the begin/end/abort+rollback. Thanks for the pointer, but it seems like Tanger's

Greetings! Short version: -------------- I cannot rename or delete the directories that have been used in the past (i.e. files or subdirectories created within). Everything else is fine, renamable, deletable. All files (regardless wethder created before or after), all directories created after the first one. I was not able to find any hint on that - neither Google, nor UseNet archive(via

Hi Torvald, On Oct 27, 2010, at 8:01, Torvald Riegel wrote: > On Tuesday 26 October 2010 14:33:02 Duncan Sands wrote: >>> transaction properties (eg, virtually atomic + isolated execution) for >>> ordinary program code. Thus, to make incrementing a counter thread-safe, >>> you could say __transaction { counter++; } and the compiler would >>> transform this

On Tuesday 26 October 2010 14:33:02 Duncan Sands wrote: > > transaction properties (eg, virtually atomic + isolated execution) for > > ordinary program code. Thus, to make incrementing a counter thread-safe, > > you could say __transaction { counter++; } and the compiler would > > transform this code so that it uses a TM library, which in turn does > > concurrency

Hi Vikram, I want to use poolalloc as a means for partitioning memory in Software Transactional Memory. We will have a paper about tuning parameters in word-based STMs in PPoPP 08, but there we use one configuration for the complete TM, which obviously has limitations in heterogenous workloads. Partitioning with poolalloc should give me (1) hopefully meaningful partitions (ie,

Hi, I would like to know whether the community is interested in getting support for Transactional Memory (TM) merged in upstream LLVM. TM basically gives you transaction properties (eg, virtually atomic + isolated execution) for ordinary program code. Thus, to make incrementing a counter thread-safe, you could say __transaction { counter++; } and the compiler would transform this code so

Hi, I recently looked quite some time for why poolalloc wouldn't transform calls to malloc() in my program, until I noticed that it handles calls to malloc() (eg, stdlib pass) -- but only transforms MallocInst's. Is there a general policy on how passes should behave? Should they handle both representations, is doing -raiseallocs the preferred way, or do we explicitely not want any

Torvald Riegel wrote: > On Monday 09 July 2007 19:33, Scott Michel wrote: >> Torvald Riegel wrote: >>> Hi, >>> >>> I'd like to see support for something like this. I have some comments, >>> and I think there is existing work that you can reuse. >> "reuse within the compiler." > > within the LLVM compiler framework, to be

Hi Torvald, > I would like to know whether the community is interested in getting support > for Transactional Memory (TM) merged in upstream LLVM. I guess not :( TM basically gives you > transaction properties (eg, virtually atomic + isolated execution) for > ordinary program code. Thus, to make incrementing a counter thread-safe, you > could say __transaction { counter++; } and

Torvald, For what are you interested in poolalloc? I'm asking because we are trying to decide how to prioritize work on it. Thanks, --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.org On Oct 27, 2007, at 11:10 AM, Torvald Riegel wrote: > Hi, > > I recently looked quite some time for why poolalloc wouldn't > transform calls > to malloc() in my program, until I

On Tuesday 13 July 2010 19:48:25 you wrote: > On Tue, Jul 13, 2010 at 10:09 AM, Torvald Riegel > > I thought that the layout of structs was supposed to be preserved (wrong > > assumption?). Otherwise, any ideas why this happens? > > It should be preserved in general; Is this a "should" or a "must"? Are there any cases in which structure layout must be

On Wed, Jul 14, 2010 at 3:20 AM, Torvald Riegel <torvald at se.inf.tu-dresden.de> wrote: > On Tuesday 13 July 2010 19:48:25 you wrote: >> On Tue, Jul 13, 2010 at 10:09 AM, Torvald Riegel >> > I thought that the layout of structs was supposed to be preserved (wrong >> > assumption?). Otherwise, any ideas why this happens? >> >> It should be preserved in

Hi, I seemingly have a simple problem, but I've spend hours reading guides & posts on this forum and I can't seem to piece together what I need. I have a dataframe where I want to divide it into two subsets: a sample, and the remainder of the dataframe in a new frame. I've tried this: split(df, sample(nrow(df), size=100, replace=FALSE)) another way would be to make a new

On Wed, Jul 14, 2010 at 10:26 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Jul 14, 2010 at 3:20 AM, Torvald Riegel > <torvald at se.inf.tu-dresden.de> wrote: >> On Tuesday 13 July 2010 19:48:25 you wrote: >>> On Tue, Jul 13, 2010 at 10:09 AM, Torvald Riegel >>> > I thought that the layout of structs was supposed to be preserved (wrong

On Wed, Jul 14, 2010 at 8:33 AM, Andrew Lenharth <andrewl at lenharth.org> wrote: > On Wed, Jul 14, 2010 at 10:26 AM, Eli Friedman <eli.friedman at gmail.com> wrote: >> On Wed, Jul 14, 2010 at 3:20 AM, Torvald Riegel >> <torvald at se.inf.tu-dresden.de> wrote: >>> On Tuesday 13 July 2010 19:48:25 you wrote: >>>> On Tue, Jul 13, 2010 at 10:09

Torvald Riegel wrote: > Hi, > > I'd like to see support for something like this. I have some comments, and I > think there is existing work that you can reuse. "reuse within the compiler." > "While the processor may spin and attempt the atomic operation more than once > before it is successful, research indicates this is extremely uncommon." > I