Message ID | 1393294423.20991.88.camel@gnopaine |
---|---|
State | New |
Headers | show |
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
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 >
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
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 >
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);