This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] centralizing vector support info in the testsuite
- From: Dorit Nuzman <DORIT at il dot ibm dot com>
- To: Janis Johnson <janis187 at us dot ibm dot com>
- Cc: bonzini at gnu dot org, fortran at gcc dot gnu dot org, gcc at gcc dot gnu dot org, Janis Johnson <janis187 at us dot ibm dot com>, pinskia at gmail dot com, rguenther at suse dot de, tobias dot schlueter at physik dot uni-muenchen dot de
- Date: Wed, 20 Dec 2006 00:11:58 +0200
- Subject: Re: [RFC] centralizing vector support info in the testsuite
Janis Johnson <janis187@us.ibm.com> wrote on 18/12/2006 20:25:47:
> On Mon, Dec 18, 2006 at 01:19:03PM +0200, Dorit Nuzman wrote:
> > Janis Johnson <janis187@us.ibm.com> wrote on 15/12/2006 03:12:44:
> > >
> > > I seem to recall from long ago that some processors support
generating,
> > > and possibly running, multiple kinds of vector instructions.
> >
> > maybe you're thinking of x86 platforms that support mmx, sse, sse2,
sse3? I
> > think in this case we'd usually want to pick the most powerful/recent
> > option (since it's usually a superset of previous options). I think if
> > you're going to have an API that returns a list of options (as you
propose
> > below) maybe we'd want to have on top of that an API that returns the
one
> > most relevant option out of that list (sse3 in the example). For
torture -
> > the API below might be more useful. I don't remember if we have other
> > targets supporting multiple kinds of vector instructions.
> >
> > > If that
> > > is the case then check_vector_support could return a list of two
> > > (possibly empty) lists of options:
> > >
> > > options that the target compiler can use to generate vector
> > > instructions
> > >
> > > options for vector instructions that the test system can run
> > >
> > > In either case, "" is not the same as an empty list, and means that
> > > vector instructions are generated by default. The lists could be
used
> > > in torture lists for testing vector code generation for multiple
kinds
> > > of vector instructions.
>
> I would only support multiple sets of options for a target if it makes
> sense to do that somewhere. Otherwise the options returned for a target
> could be the most recent one that is supported by the test compiler,
> assembler, and hardware. If there is a list returned, then the first
> set in the list would be the one to use by default.
>
> Is there a need in any set of tests to cycle through more that one set
> of vector options for a target?
>
I don't know that there's currently a need for that.
dorit
> Janis