<?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 float_args.ll</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>8bde5e58 - Delay outgoing register assignments to last.</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/Mips/GlobalISel/irtranslator/float_args.ll#8bde5e58</link>
        <description>Delay outgoing register assignments to last.The delayed stack protector feature which is currently used for SDAG (and thusallows for more commonly generating tail calls) depends on being able to extractthe tail call into a separate return block. To do this it also has to extractthe vreg-&gt;physreg copies that set up the call&apos;s arguments, since if it doesn&apos;tthen the call inst ends up using undefined physregs in it&apos;s new spliced block.SelectionDAG implementations can do this because they delay emitting registercopies until  *after* the stack arguments are set up. GISel however justprocesses and emits the arguments in IR order, so stack arguments always end uplast, and thus this breaks the code that looks for any register arg copies thatprecede the call instruction.This patch adds a thunk argument to the assignValueToReg() and custom assignmenthooks. For outgoing arguments, register assignments use this return param toreturn a thunk that does the actual generating of the copies. We collect theseuntil all the outgoing stack assignments have been done and then execute them,so that the copies (and perhaps some artifacts like G_SEXTs) are placed afterany stores.Differential Revision: https://reviews.llvm.org/D110610

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/Mips/GlobalISel/irtranslator/float_args.ll</description>
        <pubDate>Mon, 27 Sep 2021 06:20:46 +0000</pubDate>
        <dc:creator>Amara Emerson &lt;amara@apple.com&gt;</dc:creator>
    </item>
<item>
        <title>acd13994 - [GlobalISel] Re-generate some call lowering tests with the new CHECK-NEXT behaviour.</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/Mips/GlobalISel/irtranslator/float_args.ll#acd13994</link>
        <description>[GlobalISel] Re-generate some call lowering tests with the new CHECK-NEXT behaviour.

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/Mips/GlobalISel/irtranslator/float_args.ll</description>
        <pubDate>Mon, 27 Sep 2021 00:24:58 +0000</pubDate>
        <dc:creator>Amara Emerson &lt;amara@apple.com&gt;</dc:creator>
    </item>
<item>
        <title>121541fd - Mips/GlobalISel: Use more standard call lowering infrastructure</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/Mips/GlobalISel/irtranslator/float_args.ll#121541fd</link>
        <description>Mips/GlobalISel: Use more standard call lowering infrastructureThis also fixes some missing implicit uses on call instructions, addsmissing G_ASSERT_SEXT/ZEXT annotations, and some missing outgoingsext/zexts. This also fixes not respecting tablegen requested typepromotions.This starts treating f64 passed in i32 GPRs as a type of customassignment, which restores some previously XFAILed tests. This is dueto getNumRegistersForCallingConv returns a static value, but in thiscase it is context dependent on other arguments.Most of the ugliness is reproducing a hack CC_MipsO32 uses inSelectionDAG. CC_MipsO32 depends on a bunch of vectors populated fromthe original IR argument types in MipsCCState. The way this ends upworking in GlobalISel is it only ends up inspecting the most recentlyadded vector element. I&apos;m pretty sure there are cleaner ways to dothis, but this seemed easier than fixing up the current DAGhandling. This is another case where it would be easier of theCCAssignFns were passed the original type instead of only thepre-legalized ones.There&apos;s still a lot of junk here that shouldn&apos;t be necessary. Thisalso likely breaks big endian handling, but it wasn&apos;t complete/testedanyway since the IRTranslator gives up on big endian targets.

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/Mips/GlobalISel/irtranslator/float_args.ll</description>
        <pubDate>Tue, 06 Jul 2021 16:02:07 +0000</pubDate>
        <dc:creator>Matt Arsenault &lt;Matthew.Arsenault@amd.com&gt;</dc:creator>
    </item>
<item>
        <title>6a3904f1 - Mips: Mark special case calling convention handling as custom</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/Mips/GlobalISel/irtranslator/float_args.ll#6a3904f1</link>
        <description>Mips: Mark special case calling convention handling as customThe number of registers used for passing f64 in some cases is contextdependent, and thus getNumRegistersForCallingConv is sometimesinaccurate. For f64, it reports 1 but is sometimes split into 2 32-bitregisters.For GlobalISel, the generic argument assignment code expectsgetNumRegistersForCallingConv to return an accurate answer. Switch tomarking these arguments as custom so we can deal with this case as acustom assignment rather.This temporarily breaks a few globalisel tests which are fixed by afuture change to use more of the generic infrastructure.

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/Mips/GlobalISel/irtranslator/float_args.ll</description>
        <pubDate>Thu, 08 Jul 2021 23:35:45 +0000</pubDate>
        <dc:creator>Matt Arsenault &lt;Matthew.Arsenault@amd.com&gt;</dc:creator>
    </item>
<item>
        <title>92c80529 - [MIPS GlobalISel] RegBankSelect G_MERGE_VALUES and G_UNMERGE_VALUES</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/Mips/GlobalISel/irtranslator/float_args.ll#92c80529</link>
        <description>[MIPS GlobalISel] RegBankSelect G_MERGE_VALUES and G_UNMERGE_VALUESConsider large operands in G_MERGE_VALUES and G_UNMERGE_VALUES asAmbiguous during regbank selection.Introducing new InstType AmbiguousWithMergeOrUnmerge which willallow us to recognize whether to narrow scalar or use s64:fprb.This change exposed a bug when reusing data from TypeInfoForMF.Thus when Instr is about to get destroyed (using narrow scalar)clear its data in TypeInfoForMF. Internal data is saved based onInstr&apos;s address, and it will no longer be valid.Add detailed asserts for InstType and operand size.Generate generic instructions instead of MIPS target instructionsduring argument lowering and custom legalizer.Select G_UNMERGE_VALUES and G_MERGE_VALUES when proper banks areselected: {s32:gprb, s32:gprb, s64:fprb} for G_UNMERGE_VALUES and{s64:fprb, s32:gprb, s32:gprb} for G_MERGE_VALUES.Update tests. One improvement is when floating point argument ingpr(or two gprs) gets passed to another function through gprunnecessary fpr-to-gpr moves are no longer generated.Differential Revision: https://reviews.llvm.org/D74623

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/Mips/GlobalISel/irtranslator/float_args.ll</description>
        <pubDate>Wed, 19 Feb 2020 09:06:28 +0000</pubDate>
        <dc:creator>Petar Avramovic &lt;Petar.Avramovic@rt-rk.com&gt;</dc:creator>
    </item>
<item>
        <title>5a457e08 - [MIPS GlobalISel] Lower float and double arguments in registers</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/Mips/GlobalISel/irtranslator/float_args.ll#5a457e08</link>
        <description>[MIPS GlobalISel] Lower float and double arguments in registersLower float and double arguments in registers for MIPS32.When float/double argument is passed through gpr registersselect appropriate move instruction.Differential Revision: https://reviews.llvm.org/D59642llvm-svn: 356882

            List of files:
            /llvm-project-15.0.7/llvm/test/CodeGen/Mips/GlobalISel/irtranslator/float_args.ll</description>
        <pubDate>Mon, 25 Mar 2019 11:23:41 +0000</pubDate>
        <dc:creator>Petar Avramovic &lt;Petar.Avramovic@rt-rk.com&gt;</dc:creator>
    </item>
</channel>
</rss>
