This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Uros Bizjak <ubizjak at gmail dot com>
- Cc: Allan Sandfeld Jensen <carewolf at gmail dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "Gopalasubramanian, Ganesh" <Ganesh dot Gopalasubramanian at amd dot com>
- Date: Wed, 25 Dec 2013 17:50:24 -0800
- Subject: Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning
- Authentication-results: sourceware.org; auth=none
- References: <201312151954 dot 38590 dot linux at carewolf dot com> <201312241617 dot 23608 dot linux at carewolf dot com> <CAFULd4bF4bnB_Zt80noxw1YPNs9AaJ0a5Y2CazuEwGdK7zhH2A at mail dot gmail dot com> <201312252002 dot 35602 dot linux at carewolf dot com> <CAFULd4ZDqpDrR7vW=a+KsB+Rwzv3aTmZYwvsPbky6EiYD45S3w at mail dot gmail dot com> <CAMe9rOqT1DCQ5avRyiZmD5Ds-8FtBG_JBTFob38EC0iSSNoELA at mail dot gmail dot com>
On Wed, Dec 25, 2013 at 3:09 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Wed, Dec 25, 2013 at 2:26 PM, Uros Bizjak <ubizjak@gmail.com> wrote:
>> On Wed, Dec 25, 2013 at 8:02 PM, Allan Sandfeld Jensen
>> <carewolf@gmail.com> wrote:
>>> On Wednesday 25 December 2013, Uros Bizjak wrote:
>>>> On Tue, Dec 24, 2013 at 4:17 PM, Allan Sandfeld Jensen
>>>>
>>>> <carewolf@gmail.com> wrote:
>>>> >> Will libgcc/config/i386/cpuinfo.c update be a separate patch?
>>>> >> Should we use a single definition for both i386.c and libgcc?
>>>> >
>>>> > Currently they need to be in the same patch. But yes, moving the
>>>> > definition out to a common header would probably be a good idea to
>>>> > reduce potential mismatches in future.
>>>>
>>>> This could be a follow-up patch.
>>>>
>>>> > How does the patch get commited after being accepted? It has been many
>>>> > years since I last contributed to gcc, and I can not remember the rest
>>>> > of the process, and doubt it is still the same.
>>>>
>>>> Please send me ChangeLog entries, and I will commit the patch for you.
>>>>
>>>> Patch is OK for mainline.
>>>>
>>> Ah, sorry I moved the ChangeLog entries to ChangeLog.arch but it didn't get
>>> included by svn diff. I have attached it.
>>
>> Thanks, I have committed the patch with following ChangeLog:
>>
>> gcc/
>>
>> 2013-12-25 Allan Sandfeld Jensen <sandfeld@kde.org>
>> H.J. Lu <hongjiu.lu@intel.com>
>>
>> PR target/59422
>> * config/i386/i386.c (get_builtin_code_for_version): Handle
>> PROCESSOR_HASWELL, PROCESSOR_SILVERMONT, PROCESSOR_BTVER1,
>> PROCESSOR_BTVER2, PROCESSOR_BDVER3 and PROCESSOR_BDVER4.
>> Change priority of PROCESSOR_BDVER1 to P_PROC_XOP.
>> (fold_builtin_cpu): Add "ivybridge", "haswell", "bonnell",
>> "silvermont", "bobcat" and "jaguar" CPU names. Add "sse4a",
>> "fma4", "xop" and "fma" ISA names.
>>
>> libgcc/
>>
>> 2013-12-25 Allan Sandfeld Jensen <sandfeld@kde.org>
>> H.J. Lu <hongjiu.lu@intel.com>
>>
>> PR target/59422
>> * config/i386/cpuinfo.c (enum processor_types): Add AMD_BOBCAT
>> and AMD_JAGUAR.
>> (enum processor_subtypes): Add AMDFAM15H_BDVER3, AMDFAM15H_BDVER4,
>> INTEL_COREI7_IVYBRIDGE and INTEL_COREI7_HASWELL.
>> (enum processor_features): Add FEATURE_SSE4_A, FEATURE_FMA4,
>> FEATURE_XOP and FEATURE_FMA.
>> (get_amd_cpu): Handle AMD_BOBCAT, AMD_JAGUAR, AMDFAM15H_BDVER2 and
>> AMDFAM15H_BDVER3.
>> (get_intel_cpu): Handle INTEL_COREI7 and INTEL_COREI7_HASWELL.
>> (get_available_features): Handle FEATURE_FMA, FEATURE_SSE4_A,
>> FEATURE_FMA4 and FEATURE_XOP.
>>
>> testsuite/
>>
>> 2013-12-25 Allan Sandfeld Jensen <sandfeld@kde.org>
>>
>> PR target/59422
>> * gcc.target/i386/funcspec-5.c (test_fma, test_xop, test_no_fma,
>> test_no_xop, test_arch_corei7, test_arch_corei7_avx,
>> test_arch_core_avx2, test_arch_bdver1, test_arch_bdver2,
>> test_arch_bdver3, test_tune_corei7, test_tune_corei7_avx,
>> test_tune_core_avx2, test_tune_bdver1, test_tune_bdver2 and
>> test_tune_bdver3): New function prototypes.
>>
>> Patch was bootstrapped and regression tested on x86_64-pc-linux-gnu
>> {,-m32} and committed to mainline SVN.
>>
>> Uros.
>
> In config/i386/cpuinfo.c, there are
>
> case 0x3c:
> case 0x3f:
> ^^^^^^^^^^^^^^^^^^^^^^^^ Is 0x3f Haswell? I didn't find it list in Intel SDM.
This isn't published by Intel. I checked in this patch to remove
it.
> case 0x45:
> case 0x46:
> /* Haswell. */
--
H.J.
---
diff --git a/libgcc/ChangeLog b/libgcc/ChangeLog
index 7cef00a..93a51d9 100644
--- a/libgcc/ChangeLog
+++ b/libgcc/ChangeLog
@@ -1,3 +1,8 @@
+2013-12-25 H.J. Lu <hongjiu.lu@intel.com>
+
+ * config/i386/cpuinfo.c (get_intel_cpu): Remove model 0x3f from
+ Haswell.
+
2013-12-25 Allan Sandfeld Jensen <sandfeld@kde.org>
H.J. Lu <hongjiu.lu@intel.com>
diff --git a/libgcc/config/i386/cpuinfo.c b/libgcc/config/i386/cpuinfo.c
index 9543f5c..3b3e4b4 100644
--- a/libgcc/config/i386/cpuinfo.c
+++ b/libgcc/config/i386/cpuinfo.c
@@ -222,7 +222,6 @@ get_intel_cpu (unsigned int family, unsigned int
model, unsigned int brand_id)
__cpu_model.__cpu_subtype = INTEL_COREI7_IVYBRIDGE;
break;
case 0x3c:
- case 0x3f:
case 0x45:
case 0x46:
/* Haswell. */