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, 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. 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
