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

[Dorit Nuzman <DORIT at il dot ibm dot com>]

Janis Johnson <janis187@us.ibm.com> wrote on 15/12/2006 03:12:44:

> Checks for vector instruction support are spreading throughout the
> testsuite.  I'd like to pull the basic logic into a single place that
> can be referenced wherever it's needed.  What's there now isn't always
> consistent and there might be new things we can do if the information
> is presented in a convenient way, so I'd like some advice.
>
> The following .exp files currently check whether various targets can
> generate and run vector instructions and provide command line options
> for specific targets:
>
>   gcc.dg/vmx/vmx.exp
>   gcc.dg/vect/vect.exp
>   g++.dg/vect/vect.exp
>   gfortran.dg/vect/vect.exp
>   lib/fortran-torture.exp
>
> The following procedures are used only by other procedures:
>
>   check_effective_target_mpaired_single (for mips)
>   check_alpha_max_hw_available
>   check_vmx_hw_available
>
> The following effective targets are used in individual tests as well
> as within .exp files:
>
>   powerpc_altivec_ok
>   vect_cmdline_needed (checks i?86, x86_64, ia64)
>
> I'd like to pull all of the logic into a single procedure I'll call
> check_vector_support that will return a list where the first element is
>
>   0  no vector support
>   1  can generate but not run vector instructions
>   2  can generate and run vector instructions
>
> The second element returned is the command line options needed to
> generate vector instructions for the current effective target.  This
> information can be used in the .exp files that currently do all these
> checks themselves,

sounds excellent (at least in terms of what we need in the vect.exp files),
thanks!

> and can be used for new target-independent effective
> targets to replace vmx_hw and powerpc_altivec_ok:
>
>   vect_gen  (ok to generate vector instructions)
>   vect_run  (ok to generate and run vector instructions)
>
> The existing proc for vect_cmdline_needed would also use the results of
> check_vector_support and would support all targets.
>
> Current handling of i?86, x86_64, and ia64 is confusing.  Some places
> use "-msse2" for all of these, but the procedure
> check_effective_target_vect_cmdline_needed says no options are needed
> for ia64 or for LP64 x86_64 and i?86.
>
> 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.

thanks,
dorit

> 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.
>
> Comments?
>
> Janis