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 Mon, Aug 22, 2011 at 11:50 AM, Sriraman Tallam <tmsriram@google.com> wrote:
> On Mon, Aug 22, 2011 at 9:02 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Mon, Aug 22, 2011 at 8:56 AM, Michael Matz <matz@suse.de> wrote:
>>> Hi,
>>>
>>> On Mon, 22 Aug 2011, H.J. Lu wrote:
>>>
>>>> >> 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.
>>>> >
>>>>
>>>> It sounds more complicated than necessary. ?Why not just do it
>>>> on demand like glibc does?
>>>
>>> Ehm, the only difference would be to not have a ctor in libgcc that looks
>>> like so:
>>>
>>> void __attribute__((constructor)) bla(void)
>>> {
>>> ?__cpu_indicator_init ();
>>> }
>>>
>>> I don't see any complication.?
>>>
>>
>> Order of constructors. ?A constructor may call functions
>> which use __cpu_indicator.
>
> I have a suggestion that is a hybrid of the proposed solutions here:
>
> 1) Make a constructor in every module that calls
> "__cpu_indicator_init" and make it to be the first constructor to run.
> ?Will this solve the ordering problem?
> 2) Change __cpu_indicator_init to run only once by using a variable to
> check if it has been run before.
>
> So, each module's constructor will call __cpu_indicator_init but the
> CPUID insns are only done once. I also avoid the extra overhead of
> having to check if "__cpu_indicator_init" is called from within the
> binary. Will this work?
>

Please make it simple like

if __cpu_indicator is not initialized then
    call __cpu_indicator_init
fi

use  __cpu_indicator


-- 
H.J.


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