This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: patch: cleanup gcc.dg/vect/


> > I am not sure if we may still want to run the tests, especially the
compile
> > tests even if the HW is not available.  Dorit?

I prefer Janis's suggestion:

> Compiling and the checks in the dg-final step are useful, so perhaps we
> can change the "dg-do" option from "run" to "compile" if the hardware
> doesn't have vector support, as is done for the gcc.dg/vmx tests.


As for the -mpowerpc64 issue:

> I'm making progress but have questions for Dorit and others who have
> contributed the vect tests:
>
> Tests vect-72.c and vect-73.c use -mpowerpc64.  That has no effect on a
> biarch compiler; should it have been -m64?

no. (by the way, it's actually tests vect-82_64.c and vect-83_64.c,
right?).

-mpowerpc64 makes a difference when handling the following loop:
      for (i=0 to 4) a_DImode[i] = 0.

Before, the vectorizer vectorized this loop, using TImode:
      for (i=0 to 2) vect_pa_TImode[i] = 0.
If -mpowerpc64 was used, this was recognized as movti_ppc64, and later
expanded into two movdi_internal64.
If -mpowerpc64 was not used, we ICEd in recog.

Now, the vectorizer does not try to vectorize this loop anymore because
TImode is not a VECTOR_MODE_P.


Janis, Aldi - thanks for cleaning up the vect tests!

dorit.





                                                                                                                                    
                      Janis Johnson                                                                                                 
                      <janis187@us.ibm.        To:       Janis Johnson <janis187@us.ibm.com>                                        
                      com>                     cc:       Aldy Hernandez <aldyh@redhat.com>, gcc-patches@gcc.gnu.org, Dorit          
                                                Naishlos/Haifa/IBM@IBMIL                                                            
                      19/10/2004 01:54         Subject:  Re: patch: cleanup gcc.dg/vect/                                            
                                                                                                                                    




On Mon, Oct 18, 2004 at 03:06:09PM -0700, Janis Johnson wrote:
> On Mon, Oct 18, 2004 at 03:41:19PM -0400, Aldy Hernandez wrote:
> > I have also disabled the powerpc tests when VMX is not available.
Right
> > now, we indiscriminately try to run tests when hardware may not be
> > available.
> >
> > I am not sure if we may still want to run the tests, especially the
compile
> > tests even if the HW is not available.  Dorit?  Folks?  If this is the
> > case, then we can just disable the tests for powerpc-*-*spe.
>
> Compiling and the checks in the dg-final step are useful, so perhaps we
> can change the "dg-do" option from "run" to "compile" if the hardware
> doesn't have vector support, as is done for the gcc.dg/vmx tests.  I'll
> take a look and let you know if it will fit in nicely with the vect test
> infrastructure.

I'm making progress but have questions for Dorit and others who have
contributed the vect tests:

Tests vect-72.c and vect-73.c use -mpowerpc64.  That has no effect on a
biarch compiler; should it have been -m64?  I always test a biarch
compiler with both -m32 and -m64 anyway so using -m64 in a test would
cause problems, or at least confusion.  There are tests in other parts
of the testsuite that are only relevant for either -m32 or -m64 that
we're trying to figure out how to handle.

There are currently 91 tests in gcc.dg/vect and only 31 of them specify
mipsisa64*-*-* as a target.  Is it an oversight that most of the other
tests are not run for mipsisa64?

Janis




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]