[RFC, x86] Changes for AVX and AVX2 processors
Uros Bizjak
ubizjak@gmail.com
Sun Dec 30 13:21:00 GMT 2012
On Sat, Dec 29, 2012 at 5:57 PM, Vladimir Yakovlev <vbyakovl23@gmail.com> wrote:
> I did changes. Please take a look.
>
> 2012/12/29, Uros Bizjak <ubizjak@gmail.com>:
>> On Sat, Dec 29, 2012 at 6:26 AM, Vladimir Yakovlev <vbyakovl23@gmail.com>
>> wrote:
>>
>>> processor_alias_table contains the same processor type for all
>>> "corei7", "corei7-avx", "core-avx-i" and "core-avx2". At least, it has
>>> consequence on checking x86_avx256_split_unaligned_load &
>>> ix86_tune_mask: for all these processors it results the same. Moreover
>>> we cannot turn new features on for AVX/AVX2 using
>>> initial_ix86_tune_features.
>>
>> corei7, corei7-avx and core-avx-i are all based on sandybridge (=
>> PROCESSOR_COREI7) architecture. The only problematic entry is
>> core-avx2, which should be based on new architecture. I propose
>> PROCESSOR_HASWELL, in the same way as we have PROCESSOR_NOCONA.
@@ -2467,6 +2470,7 @@
"nocona",
"core2",
"corei7",
+ "coreavx2",
"atom",
"geode",
"k6",
This string should match processor_alias_table name, so "core-avx2".
@@ -28709,6 +28716,10 @@
arg_str = "corei7";
priority = P_PROC_SSE4_2;
break;
+ case PROCESSOR_HASWELL:
+ arg_str = "core_avx2";
+ priority = P_PROC_SSE4_2;
+ break;
case PROCESSOR_ATOM:
arg_str = "atom";
priority = P_PROC_SSSE3;
This is part of a processor dispatcher functionality. To support this
functionality, some more changes are needed, so it is IMO best to
leave this part out for now. I would also like the author of processor
dispatcher to review changes in this area.
On a related note, it looks to me that corei7 should declare
P_PROC_AVX here (this change should be part of another patch).
Other than that , the patch looks OK, but please repost final version
with a correct ChangeLog.
Uros.
More information about the Gcc-patches
mailing list