On Thu, Aug 18, 2011 at 6:10 AM, Michael Matz <[email protected]> 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. >
