[llvm-bugs] [Bug 44140] New: XMM constant wrongly hoisted past uses of corresponding YMM register

[via llvm-bugs]

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

            Bug ID: 44140
           Summary: XMM constant wrongly hoisted past uses of
                    corresponding YMM register
           Product: libraries
           Version: 9.0
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: edy.burt at gmail.com
                CC: craig.topper at gmail.com, llvm-bugs at lists.llvm.org,
                    llvm-dev at redking.me.uk, spatel+llvm at rotateright.com

Created attachment 22866
  --> https://bugs.llvm.org/attachment.cgi?id=22866&action=edit
Reduced testcase LLVM IR

See attached LLVM IR for a reduced testcase, which, when compiled (via llc + C
compiler), and executed:
* as-is: exits with -1 (indicating corruption of %data)
* after removing win64cc (from @opaque's definition and call): exits
successfully (indicating %data has the correct value)

My understanding of the reduced testcase is that:

1. X86 codegen takes advantage of xmm6 being callee-saved (for win64cc) to
hoist the <i64 1010101010101010101, i64 2020202020202020202> constant across
the @opaque call and out of the (fake) loop, keeping it around in xmm6

2. the two copies (%dummy1 -> %dummy2 and %dummy2 -> %dummy3) result in enough
AVX registers being used (ymm0-ymm6) to overlap with xmm6, effectively
corrupting the latter

3. by the time of the actual store to %data, whatever happened to be in ymm6's
lower half gets stored, instead of the hoisted constant

Note: this bug was observed initially on win64 target-cpu=znver1 hosts, but it
doesn't seem to require a win64 host (just the calling convention), nor an AMD
Ryzen host (just the znver1 codegen, presumably for its cost tables, and an
AVX-capable CPU).

-- 
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/20191125/b11168fa/attachment.html>