Jingu Kang via llvm-dev
2021-Oct-27 14:15 UTC
[llvm-dev] Question about hoisting LoadInst in LICM pass using MemorySSA/AliasAnalysis
Hi All, I have a question about hoisting LoadInst in LICM pass. I am looking at below IR code. @a = dso_local local_unnamed_addr global i32** null, align 8 define dso_local void @foo(i32 %max) { entry: br label %for.cond for.cond: ; preds = %for.body, %entry %i.0 = phi i32 [ 0, %entry ], [ %inc, %for.body ] %cmp.not = icmp sgt i32 %i.0, %max br i1 %cmp.not, label %for.cond.cleanup, label %for.body for.cond.cleanup: ; preds = %for.cond ret void for.body: ; preds = %for.cond %0 = load i32**, i32*** @a, align 8, !tbaa !8 %idxprom = zext i32 %i.0 to i64 %arrayidx = getelementptr inbounds i32*, i32** %0, i64 %idxprom store i32* null, i32** %arrayidx, align 8, !tbaa !8 %inc = add nuw nsw i32 %i.0, 1 br label %for.cond, !llvm.loop !12 } I have expected the `%0 = load` is hoisted to entry block because I think it is loop invariant. However, LICM pass fails to hoist it because the MemorySSA is as below. define dso_local void @foo(i32 %max) local_unnamed_addr #0 { entry: br label %for.cond for.cond: ; preds = %for.body, %entry ; 2 = MemoryPhi({entry,liveOnEntry},{for.body,1}) %i.0 = phi i32 [ 0, %entry ], [ %inc, %for.body ] %cmp.not = icmp sgt i32 %i.0, %max br i1 %cmp.not, label %for.cond.cleanup, label %for.body for.cond.cleanup: ; preds = %for.cond ret void for.body: ; preds = %for.cond ; MemoryUse(2) MayAlias %0 = load i32**, i32*** @a, align 8, !tbaa !8 %idxprom = zext i32 %i.0 to i64 %arrayidx = getelementptr inbounds i32*, i32** %0, i64 %idxprom ; 1 = MemoryDef(2) store i32* null, i32** %arrayidx, align 8, !tbaa !8 %inc = add nuw nsw i32 %i.0, 1 br label %for.cond, !llvm.loop !12 } As we can see there is `MemoryUse(2) MayAlias` above the `%0 = load` because AliasAnalysis returns MayAlias between the ‘%0 = load’ and ‘store i32* null’. I think it could be `MemoryUse(liveOnEntry)`. How do you think about it? If I missed something, please let me know. Thanks, JinGu Kang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211027/fad26961/attachment-0001.html>
Jingu Kang via llvm-dev
2021-Oct-29 18:26 UTC
[llvm-dev] Question about hoisting LoadInst in LICM pass using MemorySSA/AliasAnalysis
Ping From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Jingu Kang via llvm-dev Sent: 27 October 2021 15:15 To: llvm-dev at lists.llvm.org Subject: [llvm-dev] Question about hoisting LoadInst in LICM pass using MemorySSA/AliasAnalysis Hi All, I have a question about hoisting LoadInst in LICM pass. I am looking at below IR code. @a = dso_local local_unnamed_addr global i32** null, align 8 define dso_local void @foo(i32 %max) { entry: br label %for.cond for.cond: ; preds = %for.body, %entry %i.0 = phi i32 [ 0, %entry ], [ %inc, %for.body ] %cmp.not = icmp sgt i32 %i.0, %max br i1 %cmp.not, label %for.cond.cleanup, label %for.body for.cond.cleanup: ; preds = %for.cond ret void for.body: ; preds = %for.cond %0 = load i32**, i32*** @a, align 8, !tbaa !8 %idxprom = zext i32 %i.0 to i64 %arrayidx = getelementptr inbounds i32*, i32** %0, i64 %idxprom store i32* null, i32** %arrayidx, align 8, !tbaa !8 %inc = add nuw nsw i32 %i.0, 1 br label %for.cond, !llvm.loop !12 } I have expected the `%0 = load` is hoisted to entry block because I think it is loop invariant. However, LICM pass fails to hoist it because the MemorySSA is as below. define dso_local void @foo(i32 %max) local_unnamed_addr #0 { entry: br label %for.cond for.cond: ; preds = %for.body, %entry ; 2 = MemoryPhi({entry,liveOnEntry},{for.body,1}) %i.0 = phi i32 [ 0, %entry ], [ %inc, %for.body ] %cmp.not = icmp sgt i32 %i.0, %max br i1 %cmp.not, label %for.cond.cleanup, label %for.body for.cond.cleanup: ; preds = %for.cond ret void for.body: ; preds = %for.cond ; MemoryUse(2) MayAlias %0 = load i32**, i32*** @a, align 8, !tbaa !8 %idxprom = zext i32 %i.0 to i64 %arrayidx = getelementptr inbounds i32*, i32** %0, i64 %idxprom ; 1 = MemoryDef(2) store i32* null, i32** %arrayidx, align 8, !tbaa !8 %inc = add nuw nsw i32 %i.0, 1 br label %for.cond, !llvm.loop !12 } As we can see there is `MemoryUse(2) MayAlias` above the `%0 = load` because AliasAnalysis returns MayAlias between the ‘%0 = load’ and ‘store i32* null’. I think it could be `MemoryUse(liveOnEntry)`. How do you think about it? If I missed something, please let me know. Thanks, JinGu Kang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211029/5258492b/attachment.html>
Neil Henning via llvm-dev
2021-Nov-01 07:47 UTC
[llvm-dev] Question about hoisting LoadInst in LICM pass using MemorySSA/AliasAnalysis
Hey JinGu! I don't know the answer to this from a MemorySSA / LICM perspective (I'm not deeply aware of their internals) - but I do remember having to fix this exact kind of issue with our Burst HPC# compiler with our own custom alias analysis. From our perspective it was safe to assume that any pointer deriving from @a couldn't alias with it, and we could make this optimization (this was really important in LLVM 6/7 timeframe if I'm remembering it right because we had a lot of cases where these kind of things would disable vectorization). Cheers, -Neil. On Fri, Oct 29, 2021 at 7:27 PM Jingu Kang via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Ping > > > > *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Jingu > Kang via llvm-dev > *Sent:* 27 October 2021 15:15 > *To:* llvm-dev at lists.llvm.org > *Subject:* [llvm-dev] Question about hoisting LoadInst in LICM pass using > MemorySSA/AliasAnalysis > > > > Hi All, > > > > I have a question about hoisting LoadInst in LICM pass. I am looking at > below IR code. > > > > @a = dso_local local_unnamed_addr global i32** null, align 8 > > > > define dso_local void @foo(i32 %max) { > > entry: > > br label %for.cond > > > > for.cond: ; preds = %for.body, > %entry > > %i.0 = phi i32 [ 0, %entry ], [ %inc, %for.body ] > > %cmp.not = icmp sgt i32 %i.0, %max > > br i1 %cmp.not, label %for.cond.cleanup, label %for.body > > > > for.cond.cleanup: ; preds = %for.cond > > ret void > > > > for.body: ; preds = %for.cond > > %0 = load i32**, i32*** @a, align 8, !tbaa !8 > > %idxprom = zext i32 %i.0 to i64 > > %arrayidx = getelementptr inbounds i32*, i32** %0, i64 %idxprom > > store i32* null, i32** %arrayidx, align 8, !tbaa !8 > > %inc = add nuw nsw i32 %i.0, 1 > > br label %for.cond, !llvm.loop !12 > > } > > > > I have expected the `%0 = load` is hoisted to entry block because I think > it is loop invariant. However, LICM pass fails to hoist it because the > MemorySSA is as below. > > > > define dso_local void @foo(i32 %max) local_unnamed_addr #0 { > > entry: > > br label %for.cond > > > > for.cond: ; preds = %for.body, > %entry > > ; 2 = MemoryPhi({entry,liveOnEntry},{for.body,1}) > > %i.0 = phi i32 [ 0, %entry ], [ %inc, %for.body ] > > %cmp.not = icmp sgt i32 %i.0, %max > > br i1 %cmp.not, label %for.cond.cleanup, label %for.body > > > > for.cond.cleanup: ; preds = %for.cond > > ret void > > > > for.body: ; preds = %for.cond > > ; MemoryUse(2) MayAlias > > %0 = load i32**, i32*** @a, align 8, !tbaa !8 > > %idxprom = zext i32 %i.0 to i64 > > %arrayidx = getelementptr inbounds i32*, i32** %0, i64 %idxprom > > ; 1 = MemoryDef(2) > > store i32* null, i32** %arrayidx, align 8, !tbaa !8 > > %inc = add nuw nsw i32 %i.0, 1 > > br label %for.cond, !llvm.loop !12 > > } > > > > As we can see there is `MemoryUse(2) MayAlias` above the `%0 = load` > because AliasAnalysis returns MayAlias between the ‘%0 = load’ and ‘store > i32* null’. I think it could be `MemoryUse(liveOnEntry)`. How do you think > about it? If I missed something, please let me know. > > > > Thanks, > > JinGu Kang > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Neil Henning Senior Software Engineer Compiler unity.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211101/75236c23/attachment.html>