search for: rauw

Hello, Does anyone know if it is possible to RAUW the Metadata? I took a look at the source for it and IIUC, it is not possible. What should I do to implement the RAUW for DINode (more precisely DILocation)? Thank you for your help, Son Tuan Vu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm....

Yes, it's still respected in this case, as the only instructions that will be deleted have been RAUW with undef. Originally, all instructions where RAUW but only non-EHPad were deleted (that means EHPad were RAUW but not deleted). Then it was later patched by not RAUW token instructions and now not deleting EHPad nor token instructions. My assumption is that the instructions we wanted to avoid R...

...someone comes to you asking for X, but what they really want is a solution to underlying problem Y, for which the best solution, once you actually analyze Y, is Z. On the contrary, I came into this expecting to work with Eric on parallelizing the backend, but consistently found that callback-based RAUW traffic for metadata took almost as much CPU. Since debug info IR is at the heart of the RAUW bottleneck, I looked into its memory layout (it's a hog). I started working on PR17891 because, besides improving the memory usage, the plan promised to greatly reduce the number of nodes (indirectly...

...vid Greene wrote: > On Tuesday 02 March 2010 17:58:57 David Greene wrote: > > > way to confirm this right now. Does it fix the bug you're seeing? > > > > Yep, it fixed it. > > Hmm...curiously, not all. More tomorrow. Ah, missed a spot in 2.5, which has a few more RAUW implementations. I think we're good. Thanks! -Dave

...esday 02 March 2010 17:58:57 David Greene wrote: >>>> way to confirm this right now. Does it fix the bug you're seeing? >>> >>> Yep, it fixed it. >> >> Hmm...curiously, not all. More tomorrow. > > Ah, missed a spot in 2.5, which has a few more RAUW implementations. > I think we're good. Ok. Are you able to produce a testcase? Does it depend on custom changes? Where does the failure happen (legalize, dagcombine, selection, etc.)? The interesting case happens when the "++UI;" code in the patch gets executed, so you could put...

...avid Majnemer <david.majnemer at gmail.com>; llvm-dev at lists.llvm.org > *Subject:* [EXT] Re: [llvm-dev] InstCombine doesn't delete instructions > with token > > > > Yes, it's still respected in this case, as the only instructions that will > be deleted have been RAUW with undef. > > > > Originally, all instructions where RAUW but only non-EHPad were deleted > (that means EHPad were RAUW but not deleted). > > Then it was later patched by not RAUW token instructions and now not > deleting EHPad nor token instructions. > > > > M...

Hello everyone, If I understand correctly after the Metadata/Value split the Metadata support of RAUW is limited by ValueAsMetadata and MDNodeFwdDecl (i.e. until cycled in MDNode are not resovled). And my question is. Is where any way to replace an MDNode which is referenced by other MDNodes w\o iterating over all MDNodes in LLMVContext to find and replace those references? Unfortunately I couldn...

...the token itself. The IR is still valid but it's wasted. The source of the issue is coming from an old patch of yours: commit 7204cff0a121ebc770cf81f7f94679ae7324daae Author: David Majnemer <david.majnemer at gmail.com> Date: Fri Nov 6 21:26:32 2015 +0000 [InstCombine] Don't RAUW tokens with undef Let SimplifyCFG remove unreachable BBs which define token instructions. llvm-svn: 252343 --- a/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp +++ b/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp @@ -3012,7 +3012,7 @@ static bool prepareICWorklistFrom...

...ct 18, at 10:27, Sean Silva <chisophugis at gmail.com> wrote: > > Derp. My bad. It would be nice in the future if you communicated this better in the OP. In the OP it sounds like you are doing this solely for memory, since there is no mention of CPU time or the excessive callback-based RAUW traffic. It's clear that you found the OP misleading. I focused this RFC on what I thought the debug info maintainers would find most compelling. FTR, it was there, but I admit I assumed (too much) prior familiarity with the problem space in order to appreciate its import: >> By lever...

...ision=57465 In order to understand the details, I tried to revert the change but the test case still passes which is not very surprising after 6 years :(. I am seeing a related new bug that causes a load that was stashed on the NodeStack and in RecordedNodes during iSel to get deleted because the RAUW during MatchAddress CSE’s the load. I am hoping that you’d still remember some of the details of why we need to modify the DAG like this. Thanks. Adam

...nality below to see whether I'm trying to break your compiler permanently. In response to my recent commits (e.g., [1]) that changed API from `MDNode` to `Value`, Eric had a really interesting idea [2] -- split metadata entirely from the `Value` hierarchy, and drop general support for metadata RAUW. After hacking together some example code, this seems overwhelmingly to me like the right direction. See the attached metadata-v2.patch for my sketch of what the current metadata primitives might look like in the new hierarchy (includes LLVMContextImpl uniquing support). The initial motivation w...

On Mon, 2008-11-03 at 23:59 -0800, Chris Lattner wrote: > On Nov 3, 2008, at 3:55 PM, heisenbug wrote: > > What about "inventing" pseudo-constants (which point to the right > > thing) and build the piece of IR with them. When done, grab mutex and > > RAUW it in. Alternatively, submit to a privileged thread that performs > > the RAUW. > > The trick is to prepare the def/use chain(s) to a degree that the > > mutex is only held a minimal time. If only IR-builder threads are > > running concurrently there is no danger that a real...

...ings out in MergeFucntions pass. While I was working on MergeFunctions pass I got several questions. I hardly tried to find all the answers by myself, but there are still two questions without answer. It is about merging functions itself (not comparing). First question is: Why sometimes we use RAUW and sometimes replaceDirectCallers. Would you help me with explanation how "overridability" and possibility to create aliases affects on our decision what to use RAUW or replaceDirectCallers? And the second question. There is a case when both "F" and "G" are overrid...

...i32 1, label %cleanup] suspend: call void @llvm.coro.end() br %return.block We no longer have to do any special handling of return block as coro.end takes care of it. Lowering of coro.suspend X 1. Split block at coro.suspend, new block becomes the resume label X 2. RAUW coro.suspend with 0 in f.resume and 1 in f.destroy 3. Replace coro.suspend with 'br %suspend' coro.end expands as before: in f => no-op in f.resume/f.destroy => ret void (+ fancy things in landing pads) Gor On Thu, Jun 9, 2016 at 4:50 PM, Eli Friedman <eli.friedman at g...

...mith <dexonsmith at apple.com> wrote: >> In response to my recent commits (e.g., [1]) that changed API from >> `MDNode` to `Value`, Eric had a really interesting idea [2] -- split >> metadata entirely from the `Value` hierarchy, and drop general support >> for metadata RAUW. > > Wow, this never occurred to me, but in hindsight seems like obviously the right direction. Yup, good on Eric here. >> Here is what we'd lose: >> >> 1. No more arbitrary RAUW of metadata. >> >> While we'd keep support for RAUW of temporary MDNo...

...mMD`. Both `User` and `MDNode` implement support for an arbitrary number of operands, but using completely incompatible mechanisms. Since `MDNode` can reference an arbitrary number of arbitrary `Value`s, it uses a subclass of `CallbackVH` called `MDNodeOperand` that costs 32B (x86-64). Moreover, RAUW is expensive. `MDUser`/`CustomMD` inherits from `User` so that its subclasses can leverage the use-list infrastructure (8B per operand, fast RAUW). > I also have to ask because I can't currently see it: what does debug info being metadata buy us? I suppose it buys us: - the guarantee...

...info concept, starting with line table entries and moving >> on to the DIDescriptor hierarchy. By leveraging the use-list >> infrastructure for metadata operands -- i.e., only using value handles >> for non-metadata operands -- we'll improve memory usage and increase >> RAUW speed. >> >> My rough plan follows. I quote some numbers for memory savings below >> based on an -flto -g bootstrap of `llvm-lto` (i.e., running `llvm-lto` >> on `llvm-lto.lto.bc`, an already-linked bitcode file dumped by ld64's >> -save-temps option) that current...

...ile I was > working on MergeFunctions pass I got several questions. I hardly tried to > find all the answers by myself, but there are still two questions without > answer. > > It is about merging functions itself (not comparing). > > First question is: > Why sometimes we use RAUW and sometimes replaceDirectCallers. Would you > help me with explanation how "overridability" and possibility to create > aliases affects on our decision what to use RAUW or replaceDirectCallers? > If we know that we're going to replace F with a thunk to G, and F is *not* we...

...ins up to the old DISubprogram still. For this part you should be able to reuse the code I'm writing for ConeFunction right now (that can re-parent a function's debug info inside a new DISubprogram). Hopefully I'll have something out for review tomorrow. > > Next attempt was to RAUW the foreign CU with the desired CU, but that fails with "MDNode::replaceAllUsesWith - expected temporary node" Non-temporary MDNodes don't have RAUW support (this was deemed too expensive). You either need to create them pointing to a temporary node and then rauw the temp node with a...

... This is something that I'm very   > much interested in solving someday, but no one is working on it at   > this time (that I'm aware of). What about "inventing" pseudo-constants (which point to the right thing) and build the piece of IR with them. When done, grab mutex and RAUW it in. Alternatively, submit to a privileged thread that performs the RAUW. The trick is to prepare the def/use chain(s) to a degree that the mutex is only held a minimal time. If only IR-builder threads are running concurrently there is no danger that a real constant vanishes, leaving behind a sta...