[llvm-bugs] [Bug 36063] New: MergedLoadStoreMotion is not actually preserving MemDep

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36063

            Bug ID: 36063
           Summary: MergedLoadStoreMotion is not actually preserving
                    MemDep
           Product: new-bugs
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: bsteinbr at gmail.com
                CC: llvm-bugs at lists.llvm.org

we recently made some slight adjustments the pass order for the Rust compiler,
and that exposed what I believe to be a bug in either MergedLoadStoreMotion or
MemDep.

The rust issue this is about is: https://github.com/rust-lang/rust/issues/47364

What's ultimately causing the failure is a misoptimization happenings in GVN,
the code looks roughly like this:

    %x = getelementptr ...
    store i64 %val, i64* %x
    // ...
    %val2 = load i64, i64* %x
    // ..
    store i64 %val2, i64* %dst

Which GVN replaces with:

    store i64 %val, i64* %x
    // ...
    store i64 undef, i64* %dst

The problem here is that before MLSM ran, the initial store of %val to %x was
in a different BB, which caused MemDep to create a local dep cache entry marked
as non-local.

MLSM then actually turned that into a local dependency, but the cache entry was
never invalidated, because the non-local dependency was never resolved, so
there is no entry in the reserve lookup tables that would have allowed
removeInstruction() to find the cache entry.

So GVN still gets a non-local result, asks MemDep to evaluate it, and gets the
uninitialized alloca instead of the store instruction as a result, causing it
to replace the store with an undef.

Unfortunately I don't have a minimized test case for this yet.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180123/6dc7d570/attachment.html>