[llvm-bugs] [Bug 43288] New: [GlobalISel] When widening from non-power of 2, Legalizer assumes zero-extending loads

[via llvm-bugs]

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

            Bug ID: 43288
           Summary: [GlobalISel] When widening from non-power of 2,
                    Legalizer assumes zero-extending loads
           Product: libraries
           Version: trunk
          Hardware: All
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: GlobalISel
          Assignee: unassignedbugs at nondot.org
          Reporter: alex.davies at iinet.net.au
                CC: llvm-bugs at lists.llvm.org, quentin.colombet at gmail.com

Legalizer assumes G_LOAD clears upper bits.

This is clearest in the comments:

        // Our strategy here is to generate anyextending loads for the smaller
        // types up to next power-2 result type, and then combine the two
larger
        // result values together, before truncating back down to the non-pow-2
        // type.
        // E.g. v1 = i24 load =>
        // v2 = i32 load (2 byte)
        // v3 = i32 load (1 byte)
        // v4 = i32 shl v3, 16
        // v5 = i32 or v4, v2
        // v1 = i24 trunc v5


v2 receives an G_ANYEXT load, so upper 16 bits are undefined. v5 then ors these
upper bits, and hopes to get something meaningful from the result => bug.

Proposed fix:

        // E.g. v1 = i24 load =>
        // v2 = zext(i16 load (2 byte))
        // v3 = i32 load (1 byte)

And in code:

        auto LargeLoad =
            MIRBuilder.buildLoad(LargeLdReg, PtrReg, *LargeMMO);

becomes:

        auto LargeLoad = MIRBuilder.buildZExt(LargeLdReg,
MIRBuilder.buildLoad(LLT::scalar(LargeSplitSize), PtrReg, *LargeMMO));

Despite the bug, the code _usually_ turns out correctly (until I managed to
break it adding a few more artifact combiners...), although this seems to be
mostly by luck as far as I can tell.

-- 
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/20190912/1c9103f7/attachment.html>