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: [4.7][google]Support for getting CPU type and feature information at run-time. (issue4893046)


On Thu, Aug 18, 2011 at 6:10 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Thu, 18 Aug 2011, Richard Guenther wrote:
>
>> > CPUID to get target features and set global vars corresponding to the
>> > features. So, the builtin should be folded by into the appropriate
>> > variable in libgcc.
>>
>> Hm, but then the variable should reside in libgcc and you'd only need an
>> extern variant in the varpool. ?I'm not sure separate constructors
>> (possibly in each module ...) would be better than a single one in
>> libgcc that would get run unconditionally.
>
> Would be my preference too.
>
>> > determining target features and setting the appropriate globals. If
>> > the new builtins are called, gcc will call __cpu_indicator_init in a
>> > constructor so that it is called exactly once. Then, gcc will fold the
>> > builtin to the appropriate global variable.
>>
>> I see, but this sounds like premature optimization to me, no? ?Considering
>> you'd do this in each module and our inability to merge those constructors
>> at link time. ?If we put __cpu_indicator, the constructor and the assorted
>> support into a separate module inside libgcc.a could we arrange it in a way
>> that if __cpu_indicator is not referenced from the program that piece isn't
>> linked in? ?(not sure if that is possible with constructors)
>
> If you make an .o file only exporting __cpu_indicator, then it won't be
> included in a link where no object file refers to that symbol. ?If you put
> the ctor for that variable in the same .o file you win.
>
> I also take issue with the large number of builtins, I'd have expected one
> single builtin returning the CPU type, and an enum that can be tested.
> That potentially requires an installed gcc private header, but I think
> enabling access to this cpu detection facility in libgcc to our users is
> worthwhile.

The CPU type builtins can probably be combined, not the feature testing ones.

David

>
>
> Ciao,
> Michael.
>


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