This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [4.7][google]Support for getting CPU type and feature information at run-time. (issue4893046)
Hi,
On Sun, 21 Aug 2011, Richard Guenther wrote:
> On Sat, Aug 20, 2011 at 11:02 PM, Richard Henderson <rth@redhat.com> wrote:
> > On 08/19/2011 02:04 AM, Richard Guenther wrote:
> >> So make sure that __cpu_indicator initially has a conservative correct
> >> value? ÂI'd still prefer the constructor-in-libgcc option - if only because
> >> then the compiler-side is much simplified.
> >>
> >
> > Err, I thought __cpu_indicator was a function, not data.
> >
> > I think we need to discuss this more...
>
> Oh, I thought it was data initialized by the constructor ...
Sriramans patch right now has a function __cpu_indicator_init which is
called from (adhoc constructed) ctors and that initializes variables
__cpu_model and __cpu_features ;-) There's no __cpu_indicator symbol :)
I think the whole initializer function and the associated data blobs have
to sit in static libgcc and be hidden. By that all shared modules
will have their own copies of the model and features (and the initializer
function) so there won't be issues with copy relocs, or cross shared lib
calls while relocating the modules. Dynamically they will contain the
same data always, but it's not many bytes, and only modules making use of
this facility will pay it.
The initializer function has to be callable from pre-.init contexts, e.g.
ifunc dispatchers. And to make life easier there should be one ctor
function calling this initializer function too, so that normal code can
rely on it being already called saving one check.
Ciao,
Michael.