[llvm-bugs] [Bug 33865] New: rendering regressions since AMDGPU: Figure out private memory regs after lowering

via llvm-bugs llvm-bugs at lists.llvm.org
Thu Jul 20 15:09:40 PDT 2017


            Bug ID: 33865
           Summary: rendering regressions since AMDGPU: Figure out private
                    memory regs after lowering
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: AMDGPU
          Assignee: unassignedbugs at nondot.org
          Reporter: adf.lists at gmail.com
                CC: llvm-bugs at lists.llvm.org

On R9 285 tonga I am seeing some rendering regressions.

The most reliable is produced with Unreal Tournament alpha, but slight more
intermittent regressions are seen with unigine valley or unreal elemental demo.

I intended to attach good and bad R600_DEBUG=vs,ps,fs from UT - but they are
too big even when .xz. The diff is huge so I don't know whether they would be
much use anyway. If requested I could upload elsewhere.

When seen, reverting/re-instating below and rebuilding will reliably
fix/re-produce, but to add some complication after initially noticing it I
thought it had been fixed already as building next days llvm apparently fixed
it. I was not testing with UT at that time, though.

commit da7ac1f435e780c84dae27af22e9559676448781
Author: Matt Arsenault <Matthew.Arsenault at amd.com>
Date:   Tue Jul 18 16:44:56 2017 +0000

    AMDGPU: Figure out private memory regs after lowering

    Introduce pseudo-registers for registers needed for stack
    access, which are replaced during finalizeLowering.
    Note these pseudo-registers are currently only used for the
    used register location, and not for determining their
    input argument register.

    This is better because it avoids the need to try to predict
    whether a call will be emitted from the IR, and also
    detects stack objects introduced by legalization.

    Test changes are from the HasStackObjects check being more
    accurate since stack objects introduced during legalization
    are now known.

    git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308325

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/20170720/46281cc4/attachment-0001.html>

More information about the llvm-bugs mailing list