search for: memoryphi

...but given that InsrtedPHIs is finite. I have a case where one element(same element is appened to InsertedPHIs) is added to InsertedPHIs every time fixupDefs is invoked. I traced the issue why this was happening. template <class RangeType> MemoryAccess *MemorySSAUpdater::tryRemoveTrivialPhi(MemoryPhi *Phi, RangeType &Operands) { // Detect equal or self arguments MemoryAccess *Same = nullptr; for (auto &Op : Operands) { // If the same or self, good so far if (Op == Phi || Op == Same) continue; // not the same, re...

...I have a case where one element(same element is appened to InsertedPHIs) > is added to InsertedPHIs every time fixupDefs is invoked. I traced the > issue why this was happening. > > > > template <class RangeType> > > MemoryAccess *MemorySSAUpdater::tryRemoveTrivialPhi(MemoryPhi *Phi, > > RangeType &Operands) { > > // Detect equal or self arguments > > MemoryAccess *Same = nullptr; > > for (auto &Op : Operands) { > > // If the same or self, good so far > > if (Op =...

...t_clang_out.ll > out 2>&1 The relevant parts of the file "out" are shown below: . . . for.body: ; preds = %for.body.lr.ph, %for.body ; 3 = MemoryPhi({for.body.lr.ph,liveOnEntry},{for.body,1}) %indvars.iv35 = phi i64 [ 0, %for.body.lr.ph ], [ %indvars.iv.next36, %for.body ] %arrayidx = getelementptr inbounds i32, i32* %b, i64 %indvars.iv35 ; MemoryUse(3) %2 = load i32, i32* %arrayidx, align 4, !tbaa !2 %arrayidx2 = getelementptr inbounds...

...t; Yes, the loop is slightly off. > > > The intention is to process any new phis added by fixupdefs. > However, it really should be InsertedPHIs.start() + StartingPHISize. > > > Even in that case it still is infinite, as there is no call to clear > already processed elements(MemoryPhi) in InsertedPHIs. fixupDefs function > only inserts new elements but not remove any that are processed. > It is not iterating over inserted phis, it is iterating over the phis added by fixupdefs. Thus, it does not matter whether things are removed from insertedphis, and it definitely is not...

...removed as and when they are processed. Yes, the loop is slightly off. The intention is to process any new phis added by fixupdefs. However, it really should be InsertedPHIs.start() + StartingPHISize. Even in that case it still is infinite, as there is no call to clear already processed elements(MemoryPhi) in InsertedPHIs. fixupDefs function only inserts new elements but not remove any that are processed. That will insert only the phis that fixupdefs added, and it will terminate as soon as fixupdefs stops adding phis. -------------- next part -------------- An HTML attachment was scrubbed... URL:...

...1 >> ; 2 = MemoryDef(4) >> store i8 16, i8* %0 >> br label %4 >> >> ; <label>:3: ; preds = %1 >> br label %4 >> >> ; <label>:4: ; preds = %3, %2 >> ; 3 = MemoryPhi({%3,4},{%2,2}) >> ; MemoryUse(3) >> %5 = load i8, i8* %0 >> ; MemoryUse(1) >> %6 = load i8, i8* %0 >> } >> >> What is the general behavior that I can expect when I insert or remove >> def/use? >> > > So far, it is built to replace all...

...file "out" are shown below: >> . >> . >> . >> >> for.body: ; preds = % >> for.body.lr.ph, %for.body >> ; 3 = MemoryPhi({for.body.lr.ph,liveOnEntry},{for.body,1}) >> %indvars.iv35 = phi i64 [ 0, %for.body.lr.ph ], [ %indvars.iv.next36, >> %for.body ] >> %arrayidx = getelementptr inbounds i32, i32* %b, i64 %indvars.iv35 >> ; MemoryUse(3) >> %2 = load i32, i32* %arrayidx, align 4, !...

...d to provide an alias set like abstraction over MemorySSA. What am I > missing? > Yes, it is straight forward to have alias sets on top of MemorySSA, but it will likely lose most of MemorySSA's benefits. > Here's a sketch of how I'd think to approach this: > > Visit the MemoryPhi nodes in a loop. Every interesting promotion case > (mod in loop) must be involved in at least one MemoryPhi cycle. > > For each MemoryPhi in the header, create a set of all MemoryDef > instructions involved. (I'm saying this in terms of instructions, but sets > of MemoryLocati...

...then, label %if.end if.then: ; preds = %entry ; 4 = MemoryDef(3) store i32 42, i32* %a, align 4 ; 5 = MemoryDef(4) store i32 32, i32* %d, align 4 br label %if.end if.end: ; preds = %if.then, %entry ; 9 = MemoryPhi({entry,3},{if.then,5}) ; MemoryUse(9) %1 = load i32, i32* %a, align 4 ; 6 = MemoryDef(9) store i32 %1, i32* %c, align 4 ; MemoryUse(9) %2 = load i32, i32* %d, align 4 ; 7 = MemoryDef(6) store i32 %2, i32* %e, align 4 ret void } Tracking back def-use chain for `%1 = load i32, i32* %...

...; preds = %entry > > ; 4 = MemoryDef(3) > > store i32 42, i32* %a, align 4 > > ; 5 = MemoryDef(4) > > store i32 32, i32* %d, align 4 > > br label %if.end > > > if.end: ; preds = %if.then, %entry > > ; 9 = MemoryPhi({entry,3},{if.then,5}) > > ; MemoryUse(9) > > %1 = load i32, i32* %a, align 4 > > ; 6 = MemoryDef(9) > > store i32 %1, i32* %c, align 4 > > ; MemoryUse(9) > > %2 = load i32, i32* %d, align 4 > > ; 7 = MemoryDef(6) > > store i32 %2, i32* %e, align...

...bug in MemorySSA. George, I wasn't sure if this was a known issue that you'll be addressing in your upcoming walker caching changes or not, so I haven't investigated it very much. The test case is attached. The bug is that the defining access for the second load is set to the loop MemoryPhi node instead of being liveOnEntry as it should be as I understand things. -- Geoff Berry Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -------------- next part -------------- diff --git...

..., label %3 ; <label>:2: ; preds = %1 ; 2 = MemoryDef(4) store i8 16, i8* %0 br label %4 ; <label>:3: ; preds = %1 br label %4 ; <label>:4: ; preds = %3, %2 ; 3 = MemoryPhi({%3,4},{%2,2}) ; MemoryUse(3) %5 = load i8, i8* %0 ; MemoryUse(1) %6 = load i8, i8* %0 } What is the general behavior that I can expect when I insert or remove def/use? Another general question: what is the use of MemorySSAUpdater? When should I use updater and when the MemorySSA API is suffic...

On Mon, Apr 27, 2015 at 4:21 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > You can't win here (believe me, i've tried, and better people than me have > tried, for years :P). > No matter what you do, the partitioning will never be 100% precise. The > only way to solve that in general is to pairwise query over the > partitioning. > > Your basic problem is

When we erase a memory access instruction, existing passes using memory ssa like GVN, NewGVN, GVNHoist and EarlyCSE uses MemorySSAUpdater to do the update before the instruction is erased. However, if we call llvm::RecursivelyDeleteTriviallyDeadInstructions to find out dead instruction recursively and memory access instructions may be erased inside the recursive process, we need a way to update

...A. George, I wasn't > sure if this was a known issue that you'll be addressing in your upcoming > walker caching changes or not, so I haven't investigated it very much. The > test case is attached. The bug is that the defining access for the second > load is set to the loop MemoryPhi node instead of being liveOnEntry as it > should be as I understand things. > > -- > Geoff Berry > Employee of Qualcomm Innovation Center, Inc. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > Linux Foundation Collaborative Project > > -----------...

...s changed in some cases, and to initialize the memory operand equivalence table properly. I'm thinking how best to solve it. In the meantime, reverting the store equivalence changes should fix most of it (there is one other bug in updateReachableEdge that won't fix, where it misses marking memoryphi's) On Tue, Dec 27, 2016 at 3:34 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Tue, Dec 27, 2016 at 3:22 PM, Nemanja Ivanovic via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I assume that this passes all the lit/lnt test cases on the plat...

(minor inline additions) On 09/13/2018 01:51 AM, Chandler Carruth wrote: > Haven't had time to dig into this, but wanted to add +Alina Sbirlea > <mailto:asbirlea at google.com> to the thread as she has been working on > promotion and other aspects of LICM for a long time here. Thanks! > On Wed, Sep 12, 2018 at 11:41 PM Philip Reames > <listmail at philipreames.com

...to initialize the memory operand equivalence > table properly. > > I'm thinking how best to solve it. > In the meantime, reverting the store equivalence changes should fix most > of it (there is one other bug in updateReachableEdge that won't fix, where > it misses marking memoryphi's) > > > On Tue, Dec 27, 2016 at 3:34 PM, Daniel Berlin <dberlin at dberlin.org> > wrote: > >> >> >> On Tue, Dec 27, 2016 at 3:22 PM, Nemanja Ivanovic via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> I assume that this...

...(!MD) > continue; > > - for (const auto &U : MD->users()) { > + for (User *U : MD->users()) { > BasicBlock *UseBlock; > // Things are allowed to flow to phi nodes over their predecessor edge. > if (auto *P = dyn_cast<MemoryPhi>(U)) { > > Modified: llvm/trunk/tools/sancov/sancov.cc > URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/sancov/sancov.cc?rev=261524&r1=261523&r2=261524&view=diff > ============================================================================== > --- llvm/trun...

...nds (%"struct.std::atomic", %"struct.std::atomic"* @x, i64 0, i32 0, i32 0) seq_cst, align 4* ; 3 = MemoryDef(2) store i32 %1, i32* @data2, align 4, !tbaa !1 br label %if.end if.end: ; preds = %entry.if.end_crit_edge, %if.then ; 8 = MemoryPhi({if.then,3},{entry.if.end_crit_edge,1}) %2 = phi i32 [ %.pre, %entry.if.end_crit_edge ], [ %1, %if.then ] ; 4 = MemoryDef(8) store i32 %2, i32* @data3, align 4, !tbaa !1 *; 5 = MemoryDef(4)* * %3 = load atomic i32, i32* getelementptr inbounds (%"struct.std::atomic", %"struct.std...