search for: resumptive

...ss them with high quality, with interesting optimization potential, and without loss of semantic fidelity. Furthermore, I believe that LLVM IR should be able to reasonably express the full range of behavior of the platform's exceptions implementation. Specifically, we should able to implement resumptive exception handlers on unwinders that support them, which (to summarize briefly) is all of above. Now, obviously, actually implementing codegen lowering for resumptive handlers is not an immediate priority (although the problems there roughly coincide with the problems we'd face in implementing...

...want to consider immediately. Those are interesting questions, but they're separate questions, and we should settle on these basic requirements first. For example, if it's a real goal to make LLVM IR capable of supporting a wider range of unwinders than it currently can — at a gloss, non-resumptive EH with a single, non-reentrant landing pad per region and LSDA layout approximating what's consumed by __gxx_personality_v0 — then that touches on almost everything else. Contrariwise, if we're only really interested in finding a better fix to the current IPO problems, then maybe we can g...

On Thu, Jun 9, 2016 at 1:49 PM, Eli Friedman <eli.friedman at gmail.com> wrote: >> Right... but that doesn't mean the call to the suspend intrinsic has to be >> the last non-terminator instruction in the basic block before you run >> CoroSplit. You can split the basic block in CoroSplit so any instructions >> after the suspend call are part of a different basic

Hi John, I'll read your email with greater care along the week, but I have added a page on the wiki to help us organise our thoughts. http://wiki.llvm.org/Exception_Handling I'll change it as I go reading your email, but for now, I've separated into each of the requirements you said. New ones could be added, existing ones merged, but the most important is to add more complete

Hi David: >> How do you deal with basic blocks which appear to be used by multiple parts >> of the coroutine? We handled this in WinEHPrepare by cloning any BBs which >> were shared. I experimented with several approaches, but, cloning ended up being the simplest and most reliable. Suspend points express three different control flows that can happen at the suspend point: 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 solutions. I will dare a comment on this topic well over my head, so my answer will probably only reflect my ignoranc...

[Patch 4/4]: Xend interface for HVM S3 - extend "xm resume <domid>" to be able to S3 resume HVM domain. - when user issue "xm resume" command for HVM domain, xend will use xc lib API to call HVMOP_s3_resume hypercall. Note: it may not appropriate use xm resume for HVM s3, since xm resume is originally designed for save/restor purpose. It will be fine that

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

Hi to all, The system is running Debian 12 with Gluster 10. All systems are using the same versions. I try to encrypt the communication between the peers and the clients via TLS. The encryption between the peers works, but when I try to mount the volume on the client I always get an error. What have I done? 1. all hosts and clients can resolve the name of all systems involved. 2. the

On May 4, 2011, at 8:23 AM, Evan Cheng wrote: >> I don't know how realistic it is to model the loop buffer in the register allocator, but this would a very interesting thing to try to optimize for in a later pass. If an inner loop "almost" fits, then it would probably be worth heroic effort to try to reduce the size of it to shave off a few bytes. > > Jakob and I have

hi, I seem to have a problem with the Linux xen-network driver leaking skbs. This is probably my own fault, upon resumption after migration I call this: void network_resume(void) { struct net_device* dev = __dev_get_by_name("eth0"); MOD_DEC_USE_COUNT; network_open(dev); } -- which works fine. However, in network_open() the call to NETOP_RESET_RINGS seems to clear all the

On Jul 27, 2011, at 10:27 AM, Peter Lawrence wrote: > 1) it is good to see that the "exception regions" idea has been abandoned, it is mathematically > inconsistent with modern optimization theory, and at best would require extra passes to translate > into/outof that representation form. > Yeah. I didn't want to obscure the main proposal by inappropriate nomenclature.

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)

Hi Stefan, Does the combined?glusterfs.ca includes client nodes pem? Also this file need to be placed in Client node as well. -- Aravinda Kadalu Technologies ---- On Fri, 26 Jan 2024 15:14:39 +0530 Stefan Kania <stefan at kania-online.de> wrote --- Hi to all, The system is running Debian 12 with Gluster 10. All systems are using the same versions. I try to encrypt the

> > What? Yet another EH proposal?! This one is different from the > others in that > I'm planning to start implementing this shortly. But I want your > feedback! I've > all ready gotten a lot of feedback from Chris, John, Jim, Eric, and > many others. > Now is your turn! > > Please read this proposal and send me your comments, suggestions, > and

Hi Eli: >> semantics of the fork intrinsic... thinking about it a bit more, I think >> you're going to run into problems with trying to keep around a return block >> through optimizations: How about this? Make all control flow explicit (duh). declare i8 coro.suspend([...]) returns: 0 - resume 1 - cleanup anything else - suspend Now we can get

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 =

https://bugzilla.mindrot.org/show_bug.cgi?id=626 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |2076 Resolution|--- |FIXED CC| |djm at

The call site of nouveau_dsm_pci_probe() uses single set of output variables for all invocations. So, we must not write anything to them unless it's an NVIDIA device. Otherwise, if we are called with another device after the NVIDIA device, we'll clober the result of the NVIDIA device. For example, if the other device doesn't have _PR3 resources, the detection later would miss the

Just updated CentOS 9 Stream on a Lenovo T17 Gen 4 Intel and not it won't suspend with the following error: [ 52.604998] Restarting kernel threads ... done. [ 52.605111] OOM killer enabled. [ 52.605111] Restarting tasks ... done. [ 52.606604] random: crng reseeded on system resumption [ 52.616014] thermal thermal_zone9: failed to read out thermal zone (-61) [ 52.791625] PM: