Janis Johnson <[EMAIL PROTECTED]> wrote on 18/12/2006 20:25:47: > 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? >
I don't know that there's currently a need for that. dorit > Janis
