similar to: Why is lldb telling me "variable not available"?

Apologies for the slow response here Jeremy. Your reply has been incredibly helpful so far, I just need to try adding 'llvm.dbg.addr' myself to confirm that works. Thank you! - Brian Gesiak On Thu, Feb 6, 2020 at 11:04 AM Jeremy Morse <jeremy.morse.llvm at gmail.com> wrote: > Hi Brian, > > Thanks for working on coroutines, the debugging experience, and in > particular

I haven't fully parsed this thread (sorry!), but I wanted to briefly mention that the SafeStack & ASan passes both do something similar (I think): move local variables backed by allocas onto a separate stack. These passes use replaceDbgDeclare to rewrite dbg.declares s.t. they point into the new stack. After that, llvm presumably runs LowerDbgDeclare (usually via InstCombine), but all the

Vedant, Jeremy, Thanks a ton! I copied ASan's use of 'replaceDbgDeclare', think that worked! https://github.com/modocache/llvm-project/commit/afbc04e1dcba has some extremely quick and dirty changes I made (with no tests!), and a link to a Gist with the LLVM IR and DWARF produced, https://gist.github.com/modocache/6f29093ba2827946011b422ed3bd2903. There's only one kink: the spot

Hi Brian, On Tue, Feb 25, 2020 at 7:43 PM Brian Gesiak <modocache at gmail.com> wrote: > In other words, the value of %i is stored on the frame object, on the > heap, at an offset of 7 into the frame. I'm beginning to think a > fundamental fix for this issue would be to stop replacing > llvm.dbg.declare with llvm.dbg.value, and instead replace the > llvm.dbg.declare with

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

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'. You can see an example of the assert in this 26-line C++ file here: https://godbolt.org/g/Gw9UZq Note that

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

Thank you for the link and the suggestion to try master! I did so and discovered that it reproduces on master for me as well. The repro script I used (unchanged from before) and the output can be found here: https://gist.github.com/modocache/d9700166067f4a155820bc57d9bee1f3 (Note that the output looks nearly identical, but it's using clang-10 from the master branch of llvm-project.) I wonder

I am trying a setup where the one loop is rewritten as two loops. This avoids the 'rem' and 'div' instructions in the index calculation (which give the loop vectorizer a hard time). However, with this setup the loop vectorizer complains about a too small loop. LV: Checking a loop in "main" LV: Found a loop: L3 LV: Found a loop with a very small trip count. This loop

I ran into an LLVM/Clang crash when attempting to do the following: 1. Build Clang from the release/9.x branch source. 2. Use the Clang from (1) to build clangd on the release/9.x branch, with LLVM_ENABLE_MODULES=On. I wrote a script to reproduce the crash: https://gist.github.com/modocache/ac366ca9673b93bb21e75d3e72162608 At the above URL, you'll find a script `repro.sh` that reproduces

In the case when coming from C it was probably the loop unroller and SLP vectorizer which vectorized the code. Potentially I could do the same in the IR. However, the loop body that is generated in the IR can get very large. Thus, the loop unroller will refuse to unroll the loop in a large number of (important) cases. Isn't there a way to convince the loop vectorizer that it should

Hi Mikhail, As Brian noted, stuff like this works better in the new pass manager. Even in the old pass manager I thought it should work though. Did you initialize the pass, via `INITIALIZE_PASS_DEPENDENCY(PostDominatorTreeWrapperPass)`? Did you require it, via ` AU.addRequired<PostDominatorTreeWrapperPass>();`? Btw. May I ask what you are planning to do? Cheers, Johannes On 01/07,

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

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 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 Sanjoy, >> I'm not familiar with fiber-type APIs, but I assume fiber_fork is like >> setjmp, in that it can "return twice"? Yes, user-mode stack switching API are somewhat similar to setjmp. Here are links to a doc page and implementation, just in case you are curious: http://www.boost.org/doc/libs/1_59_0/libs/context/doc/html/context/context.html

(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

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