On Monday 16 December 2013, Uros Bizjak wrote: > On Mon, Dec 16, 2013 at 10:34 AM, Uros Bizjak <ubiz...@gmail.com> wrote: > > On Sun, Dec 15, 2013 at 7:54 PM, Allan Sandfeld Jensen > > > > <carew...@gmail.com> wrote: > >> Hi again > >> > >> On Wednesday 11 December 2013, Uros Bizjak wrote: > >>> Hello! > >>> > >>> > PR gcc/59422 > >>> > > >>> > This patch extends the supported targets for function multi versiong > >>> > to also include Haswell, Silvermont, and the most recent AMD models. > >>> > It also prioritizes AVX2 versions over AMD specific pre-AVX2 > >>> > versions. > >>> > >>> Please add a ChangeLog entry and attach the complete patch. Please > >>> also state how you tested the patch, as outlined in the instructions > >>> [1]. > >>> > >>> [1] http://gcc.gnu.org/contribute.html > >> > >> Updated patch for better CPU model detection and added ChangeLog. > >> > >> The patch has been tested with the attached test.cpp. Verified that it > >> doesn't build before the patch, and that it builds after, and verified > >> it selects correct versions at runtime based on either CPU model or > >> supported ISA (tested on 3 machines: SandyBridge, IvyBridge and Phenom > >> II). > >> > >> Btw, I couldn't find anything that corresponds to gcc's btver2 arch. Is > >> that an old term for what has become the Jaguar architecture? > > > > Thanks for the patch! > > > > However, you should not change the existing order of enums in > > cpuinfo.c (enum processor_vendor, enum processor_types, enum > > processor_subtypes, enum processor_features), but new entries should > > be added at the end (before *_MAX entry, if exists) of the enum. The > > enums (enum processor_features and enum processor_model) in > > config/i386/i386.c should mirror these changes. Please see [1]. > > > > Probably, we should document this in the source... > > > > - {"sandybridge", M_INTEL_COREI7_SANDYBRIDGE}, > > + {"corei7-avx", M_INTEL_COREI7_SANDYBRIDGE}, > > > > Huh... Thanks for catching this. -march=sandybridge is not recognized... > > - {"sandybridge", M_INTEL_COREI7_SANDYBRIDGE}, > + {"corei7-avx", M_INTEL_COREI7_SANDYBRIDGE}, > + {"core-avx-i", M_INTEL_COREI7_IVYBRIDGE}, > + {"core-avx2", M_INTEL_COREI7_HASWELL}, > > Ah, no. These names are not intended to be used in -march. We can > follow the tradition and use sandybridge, ivybridge and haswell here. > I had the problem that "arch=corei7-avx" was not recognized as a valid property argument until I made that change. I thought it was the intend to merge this list of models with the canonical names, but perhaps it is an error in the new parameter validation?
Note that similarly "arch=sandybridge" is accepted as a valid property argument but then fails as an invalid argument for march. Regards `Allan
