diff mbox

Fix PR target/47385, test gcc.target/powerpc/pr37168.c fails under VSX

Message ID 20110120204758.GA17193@hungry-tiger.westford.ibm.com
State New
Headers show

Commit Message

Michael Meissner Jan. 20, 2011, 8:47 p.m. UTC 
This patch fixes the bug in PR 47385, which was noticed when we built a
compiler using the --with-cpu=power7 configure option, and it ran all tests
with an implicit -mcpu=power7.

The test case pr37168 fails if VSX instructions are enabled.  This is due to
the fact that the vector constant used has 4 single precision floating point
values, and the compiler thinks it can create this via Altivec integer
instructions (the bit value is 26, and the compiler wants to load 13 into each
word and then double it to get 26).  The case fails because in this case, V4SF
uses the VSX vector unit and not the Altivec vector unit.  The fix is to allow
either VSX or Altivec vector units.

I've built the compiler and reran the tests, and noticed no new regressions.
Is it ok to apply to the trunk?

2011-01-20  Michael Meissner  <meissner@linux.vnet.ibm.com>

	PR target/47385
	* config/rs6000/altivec.md (vector constant splitters): Add
	support for creating vector single precision constants if -mvsx is
	used and we would create the constant using Altivec primitives.

Comments

David Edelsohn Jan. 23, 2011, 12:17 a.m. UTC | #1 
On Thu, Jan 20, 2011 at 3:47 PM, Michael Meissner
<meissner@linux.vnet.ibm.com> wrote:
> This patch fixes the bug in PR 47385, which was noticed when we built a
> compiler using the --with-cpu=power7 configure option, and it ran all tests
> with an implicit -mcpu=power7.
>
> The test case pr37168 fails if VSX instructions are enabled.  This is due to
> the fact that the vector constant used has 4 single precision floating point
> values, and the compiler thinks it can create this via Altivec integer
> instructions (the bit value is 26, and the compiler wants to load 13 into each
> word and then double it to get 26).  The case fails because in this case, V4SF
> uses the VSX vector unit and not the Altivec vector unit.  The fix is to allow
> either VSX or Altivec vector units.
>
> I've built the compiler and reran the tests, and noticed no new regressions.
> Is it ok to apply to the trunk?
>
> 2011-01-20  Michael Meissner  <meissner@linux.vnet.ibm.com>
>
>        PR target/47385
>        * config/rs6000/altivec.md (vector constant splitters): Add
>        support for creating vector single precision constants if -mvsx is
>        used and we would create the constant using Altivec primitives.

Okay.

Thanks, David
diff mbox

Patch

Index: gcc/config/rs6000/altivec.md
===================================================================
--- gcc/config/rs6000/altivec.md	(revision 169016)
+++ gcc/config/rs6000/altivec.md	(working copy)
@@ -225,7 +225,7 @@  (define_insn "*altivec_movti"
 (define_split
   [(set (match_operand:VM 0 "altivec_register_operand" "")
 	(match_operand:VM 1 "easy_vector_constant_msb" ""))]
-  "VECTOR_UNIT_ALTIVEC_P (<MODE>mode) && reload_completed"
+  "VECTOR_UNIT_ALTIVEC_OR_VSX_P (<MODE>mode) && reload_completed"
   [(const_int 0)]
 {
   rtx dest = operands[0];
@@ -252,7 +252,7 @@  (define_split
 (define_split
   [(set (match_operand:VM 0 "altivec_register_operand" "")
 	(match_operand:VM 1 "easy_vector_constant_add_self" ""))]
-  "VECTOR_UNIT_ALTIVEC_P (<MODE>mode) && reload_completed"
+  "VECTOR_UNIT_ALTIVEC_OR_VSX_P (<MODE>mode) && reload_completed"
   [(set (match_dup 0) (match_dup 3))
    (set (match_dup 0) (match_dup 4))]
 {