On Mon, Dec 18, 2006 at 01:19:03PM +0200, Dorit Nuzman wrote: > Janis Johnson <[EMAIL PROTECTED]> 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
