This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Support for Runtime CPU type detection via builtins (issue5754058)


Hi,

i386 maintainers -  Is this patch ok?

Thanks,
-Sri.

On Mon, Apr 2, 2012 at 5:48 PM, Sriraman Tallam <tmsriram@google.com> wrote:
> On Mon, Apr 2, 2012 at 5:38 AM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Sat, Mar 31, 2012 at 1:03 AM, Sriraman Tallam <tmsriram@google.com> wrote:
>>> On Fri, Mar 30, 2012 at 5:47 AM, Michael Matz <matz@suse.de> wrote:
>>>> Hi,
>>>>
>>>> On Thu, 29 Mar 2012, Sriraman Tallam wrote:
>>>>
>>>>> +struct __processor_model
>>>>> +{
>>>>> + ?/* Vendor. */
>>>>> + ?unsigned int __cpu_is_amd : 1;
>>>>> + ?unsigned int __cpu_is_intel : 1;
>>>>> + ?/* CPU type. */
>>>>> + ?unsigned int __cpu_is_intel_atom : 1;
>>>>> + ?unsigned int __cpu_is_intel_core2 : 1;
>>>>> + ?unsigned int __cpu_is_intel_corei7 : 1;
>>>>> + ?unsigned int __cpu_is_intel_corei7_nehalem : 1;
>>>>> + ?unsigned int __cpu_is_intel_corei7_westmere : 1;
>>>>> + ?unsigned int __cpu_is_intel_corei7_sandybridge : 1;
>>>>> + ?unsigned int __cpu_is_amdfam10h : 1;
>>>>> + ?unsigned int __cpu_is_amdfam10h_barcelona : 1;
>>>>> + ?unsigned int __cpu_is_amdfam10h_shanghai : 1;
>>>>> + ?unsigned int __cpu_is_amdfam10h_istanbul : 1;
>>>>> + ?unsigned int __cpu_is_amdfam15h_bdver1 : 1;
>>>>> + ?unsigned int __cpu_is_amdfam15h_bdver2 : 1;
>>>>> +} __cpu_model;
>>>>
>>>> It doesn't make sense for the model to be a bitfield, a processor will
>>>> have only ever exactly one model. ?Just make it an enum or even just an
>>>> int.
>>>
>>> Not entirely true, nehalem and corei7 can be both set. However, I
>>> modified this by dividing it into types and sub types and then did
>>> what you said.
>>
>> Uh... ?then I suppose you need to document somewhere what names
>> match to what cpuid family/model (supposedly thats where your two-layer
>> hierarchy comes from, which incidentially misses one layer, the vendor?)
>
> Added documentation to extend.texi
>
> Patch available for review here:
> http://codereview.appspot.com/5754058
>
> Thanks,
> -Sri.
>
>
>>
>> Richard.
>>
>>> ? ? ? * config/i386/i386.c (build_processor_features_struct): New function.
>>> ? ? ? (build_processor_model_struct): New function.
>>> ? ? ? (make_var_decl): New function.
>>> ? ? ? (get_field_from_struct): New function.
>>> ? ? ? (fold_builtin_target): New function.
>>> ? ? ? (ix86_fold_builtin): New function.
>>> ? ? ? (ix86_expand_builtin): Expand new builtins by folding them.
>>> ? ? ? (make_cpu_type_builtin): New functions.
>>> ? ? ? (ix86_init_platform_type_builtins): Make the new builtins.
>>> ? ? ? (ix86_init_builtins): Make new builtins to detect CPU type.
>>> ? ? ? (TARGET_FOLD_BUILTIN): New macro.
>>> ? ? ? (IX86_BUILTIN_CPU_INIT): New enum value.
>>> ? ? ? (IX86_BUILTIN_CPU_IS): New enum value.
>>> ? ? ? (IX86_BUILTIN_CPU_SUPPORTS): New enum value.
>>> ? ? ? * config/i386/i386-builtin-types.def: New function type.
>>> ? ? ? * testsuite/gcc.target/builtin_target.c: New testcase.
>>>
>>> ? ? ? * libgcc/config/i386/i386-cpuinfo.c: New file.
>>> ? ? ? * libgcc/config/i386/t-cpuinfo: New file.
>>> ? ? ? * libgcc/config.host: Include t-cpuinfo.
>>> ? ? ? * libgcc/config/i386/libgcc-glibc.ver: Version symbols __cpu_model
>>> ? ? ? and __cpu_features.
>>>
>>> Patch available for review here:
>>> http://codereview.appspot.com/5754058
>>>
>>> Thanks,
>>> -Sri.
>>>
>>>
>>>>
>>>>
>>>> Ciao,
>>>> Michael.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]