<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in sgpr-spill-wrong-stack-id.mir</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>2d43955c - [AMDGPU][NFC] Refactor AMDGPUCallingConv.td</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir#2d43955c</link>
        <description>[AMDGPU][NFC] Refactor AMDGPUCallingConv.tdRename CalleeSavedRegs defs to avoid being overly specific:* CSR_AMDGPU_AGPRs_32_255 =&gt; CSR_AMDGPU_AGPRs* CSR_AMDGPU_SGPRs_30_31 + CSR_AMDGPU_SGPRs_32_105 =&gt; CSR_AMDGPU_SGPRs* CSR_AMDGPU_SI_Gfx_SGPRs_4_29 + CSR_AMDGPU_SI_Gfx_SGPRs_64_105 =&gt;  CSR_AMDGPU_SI_Gfx_SGPRs* CSR_AMDGPU_HighRegs =&gt; CSR_AMDGPU* CSR_AMDGPU_HighRegs_With_AGPRs =&gt; CSR_AMDGPU_GFX90AInsts* CSR_AMDGPU_SI_Gfx_With_AGPRs =&gt; CSR_AMDGPU_SI_Gfx_GFX90AInstsIntroduce a class RegMask to mark the cases where we use theCalleeSavedRegs class purely as an expedient way to produce a mask.Update the names of these masks to not mention &quot;CSR&quot;. Other targets alsoseem to do this, so a reasonable alternative is to actually updatetable-gen to include a new class to do this explicitly, but the currentapproach seems harmless so I opted to just make it more explicit.Reviewed By: arsenm, sebastian-neDifferential Revision: https://reviews.llvm.org/D109008

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir</description>
        <pubDate>Wed, 25 May 2022 17:17:53 +0000</pubDate>
        <dc:creator>Scott Linder &lt;Scott.Linder@amd.com&gt;</dc:creator>
    </item>
<item>
        <title>eebe841a - RegAlloc: Allow targets to split register allocation</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir#eebe841a</link>
        <description>RegAlloc: Allow targets to split register allocationAMDGPU normally spills SGPRs to VGPRs. Previously, since all registerclasses are handled at the same time, this was problematic. We don&apos;tknow ahead of time how many registers will be needed to be reserved tohandle the spilling. If no VGPRs were left for spilling, we would haveto try to spill to memory. If the spilled SGPRs were required for execmask manipulation, it is highly problematic because the lanes activeat the point of spill are not necessarily the same as at the restorepoint.Avoid this problem by fully allocating SGPRs in a separate regallocrun from VGPRs. This way we know the exact number of VGPRs needed, andcan reserve them for a second run.  This fixes the most seriousissues, but it is still possible using inline asm to make all VGPRsunavailable. Start erroring in the case where we ever would requirememory for an SGPR spill.This is implemented by giving each regalloc pass a callback whichreports if a register class should be handled or not. A few passesneed some small changes to deal with leftover virtual registers.In the AMDGPU implementation, a new pass is introduced to take theplace of PrologEpilogInserter for SGPR spills emitted during the firstrun.One disadvantage of this is currently StackSlotColoring is no longerused for SGPR spills. It would need to be run again, which willrequire more work.Error if the standard -regalloc option is used. Introduce new separate-sgpr-regalloc and -vgpr-regalloc flags, so the two runs can becontrolled individually. PBQB is not currently supported, so this alsoprevents using the unhandled allocator.

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir</description>
        <pubDate>Wed, 26 Sep 2018 23:36:28 +0000</pubDate>
        <dc:creator>Matt Arsenault &lt;Matthew.Arsenault@amd.com&gt;</dc:creator>
    </item>
<item>
        <title>fae05692 - CodeGen: Print/parse LLTs in MachineMemOperands</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir#fae05692</link>
        <description>CodeGen: Print/parse LLTs in MachineMemOperandsThis will currently accept the old number of bytes syntax, and convertit to a scalar. This should be removed in the near future (I think Iconverted all of the tests already, but likely missed a few).Not sure what the exact syntax and policy should be. We can continueprinting the number of bytes for non-generic instructions to avoidtest churn and only allow non-scalar types for generic instructions.This will currently print the LLT in parentheses, but accept parsingthe existing integers and implicitly converting to scalar. Theparentheses are a bit ugly, but the parser logic seems unable to dealwithout either parentheses or some keyword to indicate the start of atype.

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir</description>
        <pubDate>Thu, 20 May 2021 02:25:51 +0000</pubDate>
        <dc:creator>Matt Arsenault &lt;Matthew.Arsenault@amd.com&gt;</dc:creator>
    </item>
<item>
        <title>3bffb1cd - [AMDGPU] Use single cache policy operand</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir#3bffb1cd</link>
        <description>[AMDGPU] Use single cache policy operandReplace individual operands GLC, SLC, and DLC with a single cache_policybitmask operand. This will reduce the number of operands in MIR and I hopethe amount of code. These operands are mostly 0 anyway.Additional advantage that parser will accept these flags in any order unlikenow.Differential Revision: https://reviews.llvm.org/D96469

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir</description>
        <pubDate>Tue, 09 Feb 2021 00:36:10 +0000</pubDate>
        <dc:creator>Stanislav Mekhanoshin &lt;Stanislav.Mekhanoshin@amd.com&gt;</dc:creator>
    </item>
<item>
        <title>a8d9d507 - [AMDGPU] gfx90a support</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir#a8d9d507</link>
        <description>[AMDGPU] gfx90a supportDifferential Revision: https://reviews.llvm.org/D96906

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir</description>
        <pubDate>Wed, 17 Feb 2021 21:37:46 +0000</pubDate>
        <dc:creator>Stanislav Mekhanoshin &lt;Stanislav.Mekhanoshin@amd.com&gt;</dc:creator>
    </item>
<item>
        <title>5ab17021 - [AMDGPU] Remove scratch rsrc from spill pseudos</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir#5ab17021</link>
        <description>[AMDGPU] Remove scratch rsrc from spill pseudosDifferential Revision: https://reviews.llvm.org/D91110

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir</description>
        <pubDate>Tue, 10 Nov 2020 00:40:35 +0000</pubDate>
        <dc:creator>Stanislav Mekhanoshin &lt;Stanislav.Mekhanoshin@amd.com&gt;</dc:creator>
    </item>
<item>
        <title>60b1967c - [AMDGPU] Add Scratch Wave Offset to Scratch Buffer Descriptor in entry functions</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir#60b1967c</link>
        <description>[AMDGPU] Add Scratch Wave Offset to Scratch Buffer Descriptor in entry functionsAdd the scratch wave offset to the scratch buffer descriptor (SRSrc) inthe entry function prologue. This allows us to removes the scratch waveoffset register from the calling convention ABI.As part of this change, allow the use of an inline constant zero for theSOffset of MUBUF instructions accessing the stack in entry functionswhen a frame pointer is not requested/required. Entry functions withcalls still need to set up the calling convention ABI stack pointerregister, and reference it in order to address arguments of calledfunctions. The ABI stack pointer register remains unswizzled, but is nowwave-relative instead of queue-relative.Non-entry functions also use an inline constant zero SOffset forwave-relative scratch access, but continue to use the stack and framepointers as before. When the stack or frame pointer is converted to aswizzled offset it is now scaled directly, as the scratch wave offset nolonger needs to be subtracted first.Update llvm/docs/AMDGPUUsage.rst to reflect these changes to the callingconvention.Tags: #llvmDifferential Revision: https://reviews.llvm.org/D75138

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir</description>
        <pubDate>Tue, 21 Jan 2020 22:27:57 +0000</pubDate>
        <dc:creator>Scott Linder &lt;Scott.Linder@amd.com&gt;</dc:creator>
    </item>
<item>
        <title>40c08052 - AMDGPU: Correct properties for adjcallstack* pseudos</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir#40c08052</link>
        <description>AMDGPU: Correct properties for adjcallstack* pseudosThese should be SALU writes, and these are lowered to instructionsthat def SCC.llvm-svn: 364859

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir</description>
        <pubDate>Mon, 01 Jul 2019 22:01:05 +0000</pubDate>
        <dc:creator>Matt Arsenault &lt;Matthew.Arsenault@amd.com&gt;</dc:creator>
    </item>
<item>
        <title>5d6ee76c - Describe stack-id as an enum</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir#5d6ee76c</link>
        <description>Describe stack-id as an enumThis patch changes MIR stack-id from an integer to an enum,and adds printing/parsing support for this in MIR files. The defaultstack-id &apos;0&apos; is now renamed to &apos;default&apos;.This should make MIR tests that have stack objects with different stack-idsmore descriptive. It also clarifies code operating on StackID.Reviewers: arsenm, thegameg, qcolombetReviewed By: arsenmDifferential Revision: https://reviews.llvm.org/D60137llvm-svn: 363533

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir</description>
        <pubDate>Mon, 17 Jun 2019 09:13:29 +0000</pubDate>
        <dc:creator>Sander de Smalen &lt;sander.desmalen@arm.com&gt;</dc:creator>
    </item>
<item>
        <title>b812b7a4 - AMDGPU: Invert frame index offset interpretation</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir#b812b7a4</link>
        <description>AMDGPU: Invert frame index offset interpretationSince the beginning, the offset of a frame index has been consistentlyinterpreted backwards. It was treating it as an offset from thescratch wave offset register as a frame register. The correctinterpretation is the offset from the SP on entry to the function,before the prolog. Frame index elimination then should select eitherSP or another register as an FP.Treat the scratch wave offset on kernel entry as the pre-incrementedSP. Rely more heavily on the standard hasFP and frame pointerelimination logic, and clean up the private reservation code. Thissaves a copy in most callee functions.The kernel prolog emission code is still kind of a mess relying onchecking the uses of physical registers, which I would prefer toeliminate.Currently selection directly emits MUBUF instructions, which requireusing a reference to some register. Use the register chosen for SP,and then ignore this later. This should probably be cleaned up to usepseudos that don&apos;t refer to any specific base register until frameindex elimination.Add a workaround for shaders using large numbers of SGPRs. I&apos;m notsure these cases were ever working correctly, since as far as I cantell the logic for figuring out which SGPR is the scratch wave offsetdoesn&apos;t match up with the shader input initialization in the shaderprogramming guide.llvm-svn: 362661

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir</description>
        <pubDate>Wed, 05 Jun 2019 22:20:47 +0000</pubDate>
        <dc:creator>Matt Arsenault &lt;Matthew.Arsenault@amd.com&gt;</dc:creator>
    </item>
<item>
        <title>a6322941 - [AMDGPU] gfx1010 VMEM and SMEM implementation</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir#a6322941</link>
        <description>[AMDGPU] gfx1010 VMEM and SMEM implementationDifferential Revision: https://reviews.llvm.org/D61330llvm-svn: 359621

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir</description>
        <pubDate>Tue, 30 Apr 2019 22:08:23 +0000</pubDate>
        <dc:creator>Stanislav Mekhanoshin &lt;Stanislav.Mekhanoshin@amd.com&gt;</dc:creator>
    </item>
<item>
        <title>bc6d07ca - MIR: Allow targets to serialize MachineFunctionInfo</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir#bc6d07ca</link>
        <description>MIR: Allow targets to serialize MachineFunctionInfoThis has been a very painful missing feature that has made producingreduced testcases difficult. In particular the various registersdetermined for stack access during function lowering were necessary toavoid undefined register errors in a large percentage ofcases. Implement a subset of the important fields that need to bepreserved for AMDGPU.Most of the changes are to support targets parsing register fields andproperly reporting errors. The biggest sort-of bug remaining is forfields that can be initialized from the IR section will be overwrittenby a default initialized machineFunctionInfo section. Anotherremaining bug is the machineFunctionInfo section is still printed evenif empty.llvm-svn: 356215

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir</description>
        <pubDate>Thu, 14 Mar 2019 22:54:43 +0000</pubDate>
        <dc:creator>Matt Arsenault &lt;Matthew.Arsenault@amd.com&gt;</dc:creator>
    </item>
<item>
        <title>dcdf3ddf - AMDGPU: Cleanup / relax tests for future changes</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir#dcdf3ddf</link>
        <description>AMDGPU: Cleanup / relax tests for future changesllvm-svn: 347576

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir</description>
        <pubDate>Mon, 26 Nov 2018 17:17:07 +0000</pubDate>
        <dc:creator>Matt Arsenault &lt;Matthew.Arsenault@amd.com&gt;</dc:creator>
    </item>
<item>
        <title>921f7a27 - StackSlotColoring: Decide colors per stack ID</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir#921f7a27</link>
        <description>StackSlotColoring: Decide colors per stack IDI thought I fixed this in r308673, but that fix wasvery broken. The assumption that any frame index can be usedin place of another was more widespread than I realized.Even when stack slot sharing was disabled, this was stillreplacing frame index uses with a different ID with a differentstack slot.Really fix this by doing the coloring per-stack ID, so all ofthe coloring logically done in a separate namespace. This is a lotsimpler than trying to figure out how to change the color ifthe stack ID is different.llvm-svn: 335488

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/AMDGPU/sgpr-spill-wrong-stack-id.mir</description>
        <pubDate>Mon, 25 Jun 2018 16:05:55 +0000</pubDate>
        <dc:creator>Matt Arsenault &lt;Matthew.Arsenault@amd.com&gt;</dc:creator>
    </item>
</channel>
</rss>
