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. Ciao, Michael.
