public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
* [gcc(refs/users/aoliva/heads/testme)] [arm] adjust expectations for armv8_2-fp16-move-[12].c
@ 2023-02-23 13:49 Alexandre Oliva
  0 siblings, 0 replies; 6+ messages in thread
From: Alexandre Oliva @ 2023-02-23 13:49 UTC (permalink / raw)
  To: gcc-cvs

https://gcc.gnu.org/g:f8e53be38d8138ef4774165425cf6e8e71a7f56a

commit f8e53be38d8138ef4774165425cf6e8e71a7f56a
Author: Alexandre Oliva <oliva@adacore.com>
Date:   Thu Feb 23 10:30:55 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)" } } */

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [gcc(refs/users/aoliva/heads/testme)] [arm] adjust expectations for armv8_2-fp16-move-[12].c
@ 2023-03-03 18:47 Alexandre Oliva
  0 siblings, 0 replies; 6+ messages in thread
From: Alexandre Oliva @ 2023-03-03 18:47 UTC (permalink / raw)
  To: gcc-cvs

https://gcc.gnu.org/g:9f53b0e9ade7e5e06e02db270767e0c79b83a3e0

commit 9f53b0e9ade7e5e06e02db270767e0c79b83a3e0
Author: Alexandre Oliva <oliva@adacore.com>
Date:   Fri Mar 3 01:47:09 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)" } } */

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [gcc(refs/users/aoliva/heads/testme)] [arm] adjust expectations for armv8_2-fp16-move-[12].c
@ 2023-02-23 14:02 Alexandre Oliva
  0 siblings, 0 replies; 6+ messages in thread
From: Alexandre Oliva @ 2023-02-23 14:02 UTC (permalink / raw)
  To: gcc-cvs

https://gcc.gnu.org/g:9112025672f77ac9e9d73a52e9030ba4ba428b06

commit 9112025672f77ac9e9d73a52e9030ba4ba428b06
Author: Alexandre Oliva <oliva@adacore.com>
Date:   Thu Feb 23 11:01:19 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)" } } */

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [gcc(refs/users/aoliva/heads/testme)] [arm] adjust expectations for armv8_2-fp16-move-[12].c
@ 2023-02-23 13:57 Alexandre Oliva
  0 siblings, 0 replies; 6+ messages in thread
From: Alexandre Oliva @ 2023-02-23 13:57 UTC (permalink / raw)
  To: gcc-cvs

https://gcc.gnu.org/g:03bd9d8a1233d29ef83b7e31cc401a8fb7c2d1f0

commit 03bd9d8a1233d29ef83b7e31cc401a8fb7c2d1f0
Author: Alexandre Oliva <oliva@adacore.com>
Date:   Thu Feb 23 10:30:55 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)" } } */

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [gcc(refs/users/aoliva/heads/testme)] [arm] adjust expectations for armv8_2-fp16-move-[12].c
@ 2023-02-23 13:26 Alexandre Oliva
  0 siblings, 0 replies; 6+ messages in thread
From: Alexandre Oliva @ 2023-02-23 13:26 UTC (permalink / raw)
  To: gcc-cvs

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)" } } */

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [gcc(refs/users/aoliva/heads/testme)] [arm] adjust expectations for armv8_2-fp16-move-[12].c
@ 2023-02-16 11:13 Alexandre Oliva
  0 siblings, 0 replies; 6+ messages in thread
From: Alexandre Oliva @ 2023-02-16 11:13 UTC (permalink / raw)
  To: gcc-cvs

https://gcc.gnu.org/g:0847a0a6bec3d6d05aa1ed79c94672b69703cacd

commit 0847a0a6bec3d6d05aa1ed79c94672b69703cacd
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)" } } */

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2023-03-03 18:47 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-23 13:49 [gcc(refs/users/aoliva/heads/testme)] [arm] adjust expectations for armv8_2-fp16-move-[12].c Alexandre Oliva
  -- 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:26 Alexandre Oliva
2023-02-16 11:13 Alexandre Oliva

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).