public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Alexandre Oliva <aoliva@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc(refs/users/aoliva/heads/testme)] [arm] adjust expectations for armv8_2-fp16-move-[12].c Date: Thu, 23 Feb 2023 13:26:54 +0000 (GMT) [thread overview] Message-ID: <20230223132654.383C03858033@sourceware.org> (raw) https://gcc.gnu.org/g:123a7eef4ece99bce22d9fcc12de1cf63fd57540 commit 123a7eef4ece99bce22d9fcc12de1cf63fd57540 Author: Alexandre Oliva <oliva@adacore.com> Date: Thu Feb 16 06:52:33 2023 -0300 [arm] adjust expectations for armv8_2-fp16-move-[12].c Commit 3a7ba8fd0cda387809e4902328af2473662b6a4a, a patch for tree-ssa-sink, enabled the removal of basic blocks in ways that affected the generated code for both of these tests, deviating from the expectations of the tests. The simplest case is that of -2, in which the edge unsplitting ends up enabling a conditional return rather than a conditional branch to a set-and-return block. That looks like an improvement to me, but the condition in which the branch or the return takes place can be reasonably reversed (and, with the current code, it is), I've relaxed the pattern in the test so as to accept reversed and unreversed conditions applied to return or branch opcodes. The situation in -1 is a little more elaborate: conditional branches based on FP compares in test_select_[78] are initially expanded with CCFPE compare-and-cbranch on G{T,E}, but when ce2 turns those into a cmove, because now we have a different fallthrough block, the condition is reversed, and that lands us with a compare-and-cmove sequence that needs CCFP for UNL{E,T}. The insn output reverses the condition and swaps the cmove input operands, so the vcmp and vsel insns come out the same except for the missing 'e' (for the compare mode) in vcmp, so, since such reversals could have happened to any of the tests depending on legitimate basic block layout, I've combined the vcmp and vcmpe counts. I see room for improving cmove sequence generation, e.g. trying direct and reversed conditions and selecting the cheapest one (which would require CCFP conditions to be modeled as more expensive than CCFPE), or for some other machine-specific (peephole2?) optimization to turn CCFP-requiring compare and cmove into CCFPE compare and swapped-inputs cmove, but I haven't tried that. for gcc/testsuite/ChangeLog * gcc.target/arm/armv8_2-fp16-move-1.c: Combine vcmp and vcmpe expected counts into a single pattern. * gcc.target/arm/armv8_2-fp16-move-2.c: Accept conditional return and reversed conditions. Diff: --- gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-1.c | 3 +-- gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-2.c | 2 +- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-1.c b/gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-1.c index 009bb8d1575..444c4a33535 100644 --- a/gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-1.c +++ b/gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-1.c @@ -196,5 +196,4 @@ test_compare_5 (__fp16 a, __fp16 b) /* { dg-final { scan-assembler-not {vcmp\.f16} } } */ /* { dg-final { scan-assembler-not {vcmpe\.f16} } } */ -/* { dg-final { scan-assembler-times {vcmp\.f32} 4 } } */ -/* { dg-final { scan-assembler-times {vcmpe\.f32} 8 } } */ +/* { dg-final { scan-assembler-times {vcmpe?\.f32} 12 } } */ diff --git a/gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-2.c b/gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-2.c index fcb857f29ff..dff57ac8147 100644 --- a/gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-2.c +++ b/gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-2.c @@ -8,4 +8,4 @@ test_select (__fp16 a, __fp16 b, __fp16 c) { return (a < b) ? b : c; } -/* { dg-final { scan-assembler "bmi" } } */ +/* { dg-final { scan-assembler "bx?(mi|pl)" } } */
next reply other threads:[~2023-02-23 13:26 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-02-23 13:26 Alexandre Oliva [this message] -- strict thread matches above, loose matches on Subject: below -- 2023-03-03 18:47 Alexandre Oliva 2023-02-23 14:02 Alexandre Oliva 2023-02-23 13:57 Alexandre Oliva 2023-02-23 13:49 Alexandre Oliva 2023-02-16 11:13 Alexandre Oliva
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20230223132654.383C03858033@sourceware.org \ --to=aoliva@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).