[llvm-bugs] [Bug 36346] New: New assert: !(TSFlags & X86II::REX_W) && "REX.W requires 64bit mode."

[via llvm-bugs]

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

            Bug ID: 36346
           Summary: New assert: !(TSFlags & X86II::REX_W) && "REX.W
                    requires 64bit mode."
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: hans at chromium.org
                CC: llvm-bugs at lists.llvm.org

We're seeing this in Chromium builds, see
https://bugs.chromium.org/p/chromium/issues/detail?id=811241

Bisection points to this commit:

---
Author: lsaba
Date: Sun Feb 11 01:34:12 2018
New Revision: 324835

URL: http://llvm.org/viewvc/llvm-project?rev=324835&view=rev
Log:
[X86] Reduce Store Forward Block issues in HW

If a load follows a store and reloads data that the store has written to
memory, Intel microarchitectures can in many cases forward the data directly
from the store to the load, This "store forwarding" saves cycles by enabling
the load to directly obtain the data instead of accessing the data from cache
or memory.
A "store forward block" occurs in cases that a store cannot be forwarded to the
load. The most typical case of store forward block on Intel Core
microarchiticutre that a small store cannot be forwarded to a large load.
The estimated penalty for a store forward block is ~13 cycles.

This pass tries to recognize and handle cases where "store forward block" is
created by the compiler when lowering memcpy calls to a sequence
of a load and a store.

The pass currently only handles cases where memcpy is lowered to XMM/YMM
registers, it tries to break the memcpy into smaller copies.
breaking the memcpy should be possible since there is no atomicity guarantee
for loads and stores to XMM/YMM.
----

-- 
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/20180212/fa71532f/attachment.html>