similar to: [LLVMdev] exception cleanup examples (was: status: llvm-stack-switch)

Hello, I wanted to ask what the current status of llvm-stack-switch[1] is. Currently, we use uclib for implementing coroutines. The Problem with this is, that you either copy you stack (and invalidate pointers to lokals) or have many stacks on the heap (the is very memory inefficient). Having llvm doing some optimization there would really help. A different approach (for asymmetric coroutines)

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

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

On Apr 13, 2011, at 21:43 CDT, John McCall wrote: > And it's okay to have limited goals! I personally don't; I think we > should aim to get the IR design good enough to support crazy resumptive > languages with crazy custom unwinding schemes. But I need to know what > range of problems we're willing to consider solving before I can usefully > weigh different

Hi Charllls, I didn't really get it. Are you saying that you would execute some functions using the JIT then, later, those functions will be modified and thus need to be re-jitted? Ciao, Duncan. On 07/06/12 20:13, Charllls Alquarra wrote: > > Sorry if it comes out a bit pushy bumping my own question, but it's been really > difficult to find any info regarding this functionality

Sorry if it comes out a bit pushy bumping my own question, but it's been really difficult to find any info regarding this functionality in the mailing list archives. Just some emails i've found from people working on NaCl: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-December/046055.html  is there a branch where this is being work on, or is internal chromium project so far? Also

Hi, I want to execute functions in a module, this module will have dependencies resolved in other modules. the modules might change (dynamic compilation environment) so i would prefer not not link all the dependencies in a single monolithic module, that is, if it can be avoided I hope to use Linker::linkModules but this is always destructive. That is ok for one module depending on a single one,

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 Toralf, > I wanted to ask what the current status of llvm-stack-switch[1] is. Given that this project never appeared in this mailing list - have you tried to ask its author? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

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 =

This reminds me of Kenneth's "context" proposal from some time back: http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-April/030787.html I haven't compared the two too closely, but I thought I should throw it out there as food for thought. Reid On Mon, Apr 11, 2011 at 3:26 PM, Talin <viridia at gmail.com> wrote: > On Mon, Apr 11, 2011 at 7:34 AM, Justin Holewinski >

(Forwarding response to llvm-dev with Dave's permission.) > On Jan 10, 2018, at 11:19 AM, David Blaikie <dblaikie at gmail.com> wrote: > Optnone stops these things, doesnt it? But then, as you say, you'd have to find some way to tunnels true optnone through to the coroutine expansion pass. > Right. More importantly, we definitely want to allow internal optimization of the

That all makes sense. I don't think the name "synthetic" is all that intuitive, though. Enum attributes are pretty cheap, maybe we should try to use a name closer to what we're trying to implement? For example, we could add a new "coroutine_foo" attribute for every coroutine style we implement. We would have analysis helper functions to answer questions like "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

Hi all: I've included below a brief description of coroutine related optimization passes and some questions/thoughts related to them. Looking forward to your feedback, comments and questions. Thank you! Roadmap: ======== 1) Get agreement on coroutine representation and overall direction. .. repeat 1) until happy http://lists.llvm.org/pipermail/llvm-dev/2016-June/100838.html (Initial)

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 Mar 19, 2018, at 3:44 PM, Brian Gesiak <modocache at gmail.com> wrote: > > Hello all! > (+cc Vedant Kumar, who I've been told knows a lot about UBSan!) > > I am trying to fix an assert that occurs when the transforms in llvm/lib/Transforms/Coroutines are applied to LLVM IR that has been generated with UBSan enabled -- specifically, '-fsanitize=null'. >

(Dropped llvm-dev by accident. Putting it back) HI Eli: >> coro.barrier() doesn't work: if the address of the alloca doesn't escape, >> alias analysis will assume the barrier can't read or write the value of >> the alloca, so the barrier doesn't actually block code movement. Got it. I am new to this and learning a lot over the course of this thread. Thank you

Hi, I would like to propose a potential solution to a bug that involves coroutine and pthread_self(). Description of the bug can be found in https://bugs.llvm.org/show_bug.cgi?id=47833. Below is a summary: pthread_self() from glibc is defined with "__attribute__ ((__const__))". The const attribute tells the compiler that it does not read nor write any global state and hence always

http://llvm.org/docs/Coroutines.html#llvm-coro-size-intrinsic The @llvm.coro.size intrinsic returns a value which lowers to a constant representing the number of bytes needed for the coroutine frame of the current function. This would presumably be used to call malloc with the return value. I noticed, however, that the example code does not check for the return value of malloc being NULL. It is