diff mbox

[rs6000] Canonicalize split for unordered vector compares

Message ID 1393294423.20991.88.camel@gnopaine
State New
Headers show

Commit Message

Bill Schmidt Feb. 25, 2014, 2:13 a.m. UTC
Hi,

The pattern *vector_unordered<mode> performs a split that's intended to
match the nor<mode>3 pattern.  However, it doesn't use the proper
canonical form, so the resulting insn isn't recognized.  This patch
changes the split to use the canonical form.

Bootstrapped and tested on powerpc64{,le}-unknown-linux-gnu with no
regressions.  Is this ok for trunk?

Thanks,
Bill


2014-02-24  Bill Schmidt  <wschmidt@linux.vnet.ibm.com>

	* config/rs6000/vector.md (*vector_unordered<mode>): Change split
	to use canonical form for nor<mode>3.

Comments

David Edelsohn Feb. 25, 2014, 4:29 a.m. UTC | #1
On Mon, Feb 24, 2014 at 9:13 PM, Bill Schmidt
<wschmidt@linux.vnet.ibm.com> wrote:
> Hi,
>
> The pattern *vector_unordered<mode> performs a split that's intended to
> match the nor<mode>3 pattern.  However, it doesn't use the proper
> canonical form, so the resulting insn isn't recognized.  This patch
> changes the split to use the canonical form.
>
> Bootstrapped and tested on powerpc64{,le}-unknown-linux-gnu with no
> regressions.  Is this ok for trunk?
>
> Thanks,
> Bill
>
>
> 2014-02-24  Bill Schmidt  <wschmidt@linux.vnet.ibm.com>
>
>         * config/rs6000/vector.md (*vector_unordered<mode>): Change split
>         to use canonical form for nor<mode>3.

Okay.

Thanks, David
Bill Schmidt Feb. 25, 2014, 3:15 p.m. UTC | #2
Hi David,

Thanks.  I have this upstream for mainline now.  This problem appears to
have been introduced in GCC 4.6.  Is it ok to backport this fix to the
FSF 4.7 and 4.8 branches?

Thanks,
Bill

On Mon, 2014-02-24 at 23:29 -0500, David Edelsohn wrote:
> On Mon, Feb 24, 2014 at 9:13 PM, Bill Schmidt
> <wschmidt@linux.vnet.ibm.com> wrote:
> > Hi,
> >
> > The pattern *vector_unordered<mode> performs a split that's intended to
> > match the nor<mode>3 pattern.  However, it doesn't use the proper
> > canonical form, so the resulting insn isn't recognized.  This patch
> > changes the split to use the canonical form.
> >
> > Bootstrapped and tested on powerpc64{,le}-unknown-linux-gnu with no
> > regressions.  Is this ok for trunk?
> >
> > Thanks,
> > Bill
> >
> >
> > 2014-02-24  Bill Schmidt  <wschmidt@linux.vnet.ibm.com>
> >
> >         * config/rs6000/vector.md (*vector_unordered<mode>): Change split
> >         to use canonical form for nor<mode>3.
> 
> Okay.
> 
> Thanks, David
>
David Edelsohn Feb. 25, 2014, 4:23 p.m. UTC | #3
On Tue, Feb 25, 2014 at 10:15 AM, Bill Schmidt
<wschmidt@linux.vnet.ibm.com> wrote:
> Hi David,
>
> Thanks.  I have this upstream for mainline now.  This problem appears to
> have been introduced in GCC 4.6.  Is it ok to backport this fix to the
> FSF 4.7 and 4.8 branches?

This is okay to backport.

Thanks, David
Bill Schmidt Feb. 26, 2014, 1:51 a.m. UTC | #4
On Tue, 2014-02-25 at 11:23 -0500, David Edelsohn wrote:
> On Tue, Feb 25, 2014 at 10:15 AM, Bill Schmidt
> <wschmidt@linux.vnet.ibm.com> wrote:
> > Hi David,
> >
> > Thanks.  I have this upstream for mainline now.  This problem appears to
> > have been introduced in GCC 4.6.  Is it ok to backport this fix to the
> > FSF 4.7 and 4.8 branches?
> 
> This is okay to backport.

Well, I guess the backport won't be necessary.  It looks like the
canonical form was changed in GCC 4.9 for some unknown reason, so
previous releases don't have a bug.  This happened when the 128-bit
expanders were moved from vector.md to rs6000.md last year.  I'll check
around why the canonicalization changed at the same time.

Thanks,
Bill

> 
> Thanks, David
>
diff mbox

Patch

Index: gcc/config/rs6000/vector.md
===================================================================
--- gcc/config/rs6000/vector.md	(revision 208062)
+++ gcc/config/rs6000/vector.md	(working copy)
@@ -608,8 +608,8 @@ 
 	(ge:VEC_F (match_dup 2)
 		  (match_dup 1)))
    (set (match_dup 0)
-	(not:VEC_F (ior:VEC_F (match_dup 3)
-			      (match_dup 4))))]
+        (and:VEC_F (not:VEC_F (match_dup 3))
+                   (not:VEC_F (match_dup 4))))]
   "
 {
   operands[3] = gen_reg_rtx (<MODE>mode);