[PATCH] D144927: [GVNHoist] don't hoist callbr users into the callbr's block
Aditya Kumar via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Mar 7 10:51:40 PST 2023
hiraditya added a comment.
In D144927#4162156 <https://reviews.llvm.org/D144927#4162156>, @nickdesaulniers wrote:
> In D144927#4160250 <https://reviews.llvm.org/D144927#4160250>, @efriedma wrote:
>
>> If you're going to enable hoisting past a callbr, please add a testcase to ensure we don't hoist a load past a callbr which modifies the memory in question.
>
> Will do. Curiously, `GVNHoist::safeToHoistLdSt` returns `false` even for cases of loads not modified by callbr, so HoistGVN doesn't optimize those cases. FWICT, the call to `GVNHoist::firstInBB` is checking the callbr against itself. It looks like MemorySSA is perhaps claiming that for this input:
>
> @x = global i32 0
> @y = global i32 0
> define i32 @foo4(i1 %z) {
> entry:
> callbr void asm "", "=*m,!i"(ptr elementtype(i32) @x)
> to label %a [label %b]
>
> a: ; preds = %entry
> %0 = load i32, ptr @y, align 4
> ret i32 %0
>
> b: ; preds = %entry
> %1 = load i32, ptr @y, align 4
> ret i32 %1
> }
>
> that `callbr` is a "defining access" for the access of `@y` (IIUC)? That seems incorrect...but I'm unfamiliar with MemorySSA.
MemorySSA is a very conservative wrapper on top of alias analysis. for any global, it is unlikely to be precise.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D144927/new/
https://reviews.llvm.org/D144927
More information about the llvm-commits
mailing list