similar to: [LLVMdev] I'm new to LLVM

I saw this was mentioned briefly last year, but there seemed to be some confusion as to what coroutines entailed and the thread died out. This technique has an unfortunate number of names, but it does get a lot of use, including popular languages like Ruby. I'm currently working on a programming language called Minnow (http://www.minnow-lang.org). It's an actor-based language, where

Hi, Sorry for the vagueness. I'm starting to think about an experimental programming language based, among other things, on microthreads, or green threads, as Erlang has. I'm still under a very vague stage, just thinking on it, so I was wondering on the way this could be achieved. What I know from microthreads are things like: * They don't have their own stack * Switching between

On Thu, Apr 16, 2009 at 9:47 AM, Jonathan D. Turner <jonathan.d.turner at gmail.com> wrote: > I saw this was mentioned briefly last year, but there seemed to be > some confusion as to what coroutines entailed and the thread died out. >  This technique has an unfortunate number of names, but it does get a > lot of use, including popular languages like Ruby. > > I'm

On Thu, Apr 16, 2009 at 3:21 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: > > First, I will assume that you have read > http://www.nondot.org/sabre/LLVMNotes/ExplicitlyManagedStackFrames.txt > and if you have not, do so. I hadn't. That's very similar to what I had tried early on, but found it was actually slower than managing my own stacks lazily (on continuation,

On Jul 24, 2008, at 12:30 PM, Álvaro Castro Castilla wrote: > Hi, > > Sorry for the vagueness. > > I'm starting to think about an experimental programming language > based, among other things, on microthreads, or green threads, as > Erlang has. I'm still under a very vague stage, just thinking on it, > so I was wondering on the way this could be achieved. > >

Hello, How would you implement an Erlang feature such as the ultra-light processes? Is llvm prepared for similar situations? I would appreciate some insight on this. Thank you very much, .alvaro.castro.castilla.

Hi Álvaro, Your question is too vague to answer with any accuracy. Could you be more specific? -bw On Jul 24, 2008, at 1:08 PM, "Álvaro Castro Castilla" <alvaro.castro.castilla at gmail.co m> wrote: > Hello, > > > How would you implement an Erlang feature such as the ultra-light > processes? > Is llvm prepared for similar situations? > > I would

Nadav, The problem appears only for vectors longer than available hardware register (in doubleword elements, i.e. more than 4 on SSE4 and more than 8 on AVX). Select does weird thing. <8 x i1> mask comes as two XMM registers, select converts them to a single XMM registers (i.e. 8 x 16 bit), immediately after it converts back to two XMM registers and does blend. Conversion forth and back has

Hi all: Below is a proposal to add experimental coroutine support to LLVM. Though this proposal is motivated primarily by the desire to support C++ Coroutines [1], the llvm representation is language neutral and can be used to support coroutines in other languages as well. Clang + llvm coroutines allows you to take this code: generator<int> range(int from, int to) { for(int i =

cc llvm-dev On Thu, Jul 21, 2016 at 9:57 AM, Vadim Chugunov <vadimcn at gmail.com> wrote: > Hi Gor, > Does you design support resumption with parameter(s)? (such as Python's > generator.send(x)). I suppose the "promise" could be used for passing data > both ways, but if that's the plan, please mention this explicitly in the > design doc. > Also, how is

Hello all, It's been a month since my previous email on the topic, and since then I've done some initial work on porting the coroutines passes to the new pass manager. In total there are 6 patches -- that's a lot to review, so allow me to introduce the changes being made in each of them. # What's finished In these first 6 patches, I focused on lowering coroutine intrinsics

Nadav, You are right, ISPC may issue intrinsics as a result of AST selection. Though I believe that we should stick to LLVM IR whenever is possible. Intrinsics may appear to be boundaries for optimizations (on both data and control flow) and are generally not optimizable. LLVM may improve over time from performance stand point and we would benefit from it (or it may play against us, like in this

Hi llvmdev! I've been working on adding coroutines to LLVM. Mentioned below is the implementation plan I'm following, for suggestions, flames and other input. Using segmented stacks is a prerequisite. The idea is to associate every coroutine with a coroutine descriptor. A coroutine descriptor consists of four words: w0, w1, w2 and w3. w0 always contains the _launcher_, and invoking a

Summary I would like to propose that we add the following function attribute to LLVM: synthetic(<string>) This attribute can only be applied to functions. It is not a semantic statement about the function it decorates. It is, instead, an explicit directive to LLVM to not attempt to propagate information about the function body outside of the function, including by changing the

On 07/28/2011 05:31 PM, Sanjoy Das wrote: > Hi llvmdev! > > I've been working on adding coroutines to LLVM. Mentioned below is the > implementation plan I'm following, for suggestions, flames and other > input. Using segmented stacks is a prerequisite. I think my only comment is that, while this would probably work, implementing it in C with a bit of assembly for

lvm 3.7.0 treats pentium dual core ( cpu family 6 model 23 ) as "penryn" cpu, which triggers a serious bug : - crashs in openGL programs when llvm is used by mesa package, llvm will produces binary code with SSE4 instructions, which is not compatible with pentium dual core, because this CPU doesn't support SSE4 instructions ( bad cpu opcodes ), with llvm 3.6.2 this bug doesn't

On Oct 21, 2013, at 12:09 PM, Dmitry Babokin <babokin at gmail.com> wrote: > By the way, I'm curious, is the any reason why you focus on SSE4, not AVX? Seems that vectorizer should care the most about the latest silicon. > I am interested in looking at the SSE4 code because lowering of AVX code is more complicated, especially for masks. The problem that <8 x i1> can be

On Mon, Apr 12, 2010 at 6:15 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > I created a wiki at http://code.google.com/p/llvm-stack-switch/ > > Right now I just copied and formatted the document as-is... I'll go > back over it with your comments in mind soon.  One more question, > which you can answer here or there: > >> Point 4 is a bit confusing.

I'm very interested in seeing support for stack/context switching in LLVM, if only for prototyping language ideas. I'm particularly interested in mechanisms that would make it possible to implement full asymmetric coroutines as described in "Revisiting Coroutines" (Moura & Ierusalimschy, Feb 2009 TOPLAS). From skimming the thread and looking at the llvm-stack-switch wiki, it

Nadav, You are absolutely right, it's ISPC workload. I've checked SSE4 and it's also severely affected. We use intrinsics only for conversion <N x i32> <=> i32, i.e. movmsk.ps. For the rest we use general LLVM instructions. And I actually would really like to stick this way. We rely on LLVM's ability to produce efficient code from general LLVM IR. Relying on