Re: [RFC] centralizing vector support info in the testsuite

[Janis Johnson <janis187 at us dot ibm dot com>]

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?

Janis