[LLVMbugs] [Bug 21365] New: Mesa llvmpipe lp_test_format regression with llvm-3.6.0svn

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=21365

            Bug ID: 21365
           Summary: Mesa llvmpipe lp_test_format regression with
                    llvm-3.6.0svn
           Product: new-bugs
           Version: trunk
          Hardware: PC
               URL: https://bugs.freedesktop.org/show_bug.cgi?id=85377
                OS: All
            Status: NEW
          Keywords: regression
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: vlee at freedesktop.org
                CC: brian.e.paul at gmail.com, chandlerc at gmail.com,
                    jfonseca at vmware.com, llvmbugs at cs.uiuc.edu,
                    sroland at vmware.com
    Classification: Unclassified

llvm-3.6.0svn r220138 introduced a regression with Mesa llvmpipe lp_test_format
unit test.

$ lp_test_format 
Testing PIPE_FORMAT_B8G8R8A8_UNORM (float) ...
Testing PIPE_FORMAT_B8G8R8A8_UNORM (unorm8) ...
Testing PIPE_FORMAT_B8G8R8X8_UNORM (float) ...
Testing PIPE_FORMAT_B8G8R8X8_UNORM (unorm8) ...
Testing PIPE_FORMAT_A8R8G8B8_UNORM (float) ...
Testing PIPE_FORMAT_A8R8G8B8_UNORM (unorm8) ...
Testing PIPE_FORMAT_X8R8G8B8_UNORM (float) ...
Testing PIPE_FORMAT_X8R8G8B8_UNORM (unorm8) ...
Testing PIPE_FORMAT_B5G5R5A1_UNORM (float) ...
Testing PIPE_FORMAT_B5G5R5A1_UNORM (unorm8) ...
Testing PIPE_FORMAT_B4G4R4A4_UNORM (float) ...
Testing PIPE_FORMAT_B4G4R4A4_UNORM (unorm8) ...
Testing PIPE_FORMAT_B5G6R5_UNORM (float) ...
Testing PIPE_FORMAT_B5G6R5_UNORM (unorm8) ...
Testing PIPE_FORMAT_R10G10B10A2_UNORM (float) ...
Testing PIPE_FORMAT_R10G10B10A2_UNORM (unorm8) ...
Testing PIPE_FORMAT_L8_UNORM (float) ...
Testing PIPE_FORMAT_L8_UNORM (unorm8) ...
Testing PIPE_FORMAT_A8_UNORM (float) ...
Testing PIPE_FORMAT_A8_UNORM (unorm8) ...
Testing PIPE_FORMAT_I8_UNORM (float) ...
Testing PIPE_FORMAT_I8_UNORM (unorm8) ...
Testing PIPE_FORMAT_L8A8_UNORM (float) ...
Testing PIPE_FORMAT_L8A8_UNORM (unorm8) ...
Testing PIPE_FORMAT_L16_UNORM (float) ...
Testing PIPE_FORMAT_L16_UNORM (unorm8) ...
Testing PIPE_FORMAT_UYVY (float) ...
Testing PIPE_FORMAT_UYVY (unorm8) ...
Testing PIPE_FORMAT_YUYV (float) ...
Testing PIPE_FORMAT_YUYV (unorm8) ...
Testing PIPE_FORMAT_R32_FLOAT (float) ...
Testing PIPE_FORMAT_R32_FLOAT (unorm8) ...
Testing PIPE_FORMAT_R32G32_FLOAT (float) ...
Testing PIPE_FORMAT_R32G32_FLOAT (unorm8) ...
Testing PIPE_FORMAT_R32G32B32_FLOAT (float) ...
Testing PIPE_FORMAT_R32G32B32_FLOAT (unorm8) ...
Testing PIPE_FORMAT_R32G32B32A32_FLOAT (float) ...
Segmentation fault (core dumped)


9b2d091a9c2509a766a233a64453462faa2bdffc is the first bad commit
commit 9b2d091a9c2509a766a233a64453462faa2bdffc
Author: Chandler Carruth <chandlerc at gmail.com>
Date:   Sat Oct 18 06:36:22 2014 +0000

    [InstCombine] Do an about-face on how LLVM canonicalizes (cast (load
    ...)) and (load (cast ...)): canonicalize toward the former.

    Historically, we've tried to load using the type of the *pointer*, and
    tried to match that type as closely as possible removing as many pointer
    casts as we could and trading them for bitcasts of the loaded value.
    This is deeply and fundamentally wrong.

    Repeat after me: memory does not have a type! This was a hard lesson for
    me to learn working on SROA.

    There is only one thing that should actually drive the type used for
    a pointer, and that is the type which we need to use to load from that
    pointer. Matching up pointer types to the loaded value types is very
    useful because it minimizes the physical size of the IR required for
    no-op casts. Similarly, the only thing that should drive the type used
    for a loaded value is *how that value is used*! Again, this minimizes
    casts. And in fact, the *only* thing motivating types in any part of
    LLVM's IR are the types used by the operations in the IR. We should
    match them as closely as possible.

    I've ended up removing some tests here as they were testing bugs or
    behavior that is no longer present. Mostly though, this is just cleanup
    to let the tests continue to function as intended.

    The only fallout I've found so far from this change was SROA and I have
    fixed it to not be impeded by the different type of load. If you find
    more places where this change causes optimizations not to fire, those
    too are likely bugs where we are assuming that the type of pointers is
    "significant" for optimization purposes.

    git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220138
91177308-0d34-0410-b5e6-96231b3b80d8

:040000 040000 982ecfc2706221c9731e5e8f54346370d2fe6283
667a68ea436b53840beda4b034cceee0e87dc6eb M    lib
:040000 040000 a6f61cd09e99c468c8fdb8dd6bda10060b4f751f
cad7ad5d09cf0f43b3f47e36050c833b2debc9fc M    test
bisect run success

-- 
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/20141023/a5a63890/attachment.html>