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)
On Mon, Aug 22, 2011 at 10:39 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Aug 22, 2011 at 1:34 PM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Mon, Aug 22, 2011 at 6:02 PM, 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.
>>
>> As I said - make __cpu_indicator have a conservative
>> default value (zero). ?It is irrelevant if constructors that
>> run before initializing __cpu_indicator run with the
>> default CPU capabilities.
>>
>
> If ?IFUNC is used, this just disables IFUNC for those functions
> called with the conservative default value since they are only
> resolved once.
Huh, well. So what happens if you use __cpu_indicator from the
IFUNC selector function!? Honestly, if we care about these
corner-cases why not make __cpu_indicator a hidden function
instead.
IMHO IFUNC selectors should simply do
if (!__cpu_indicator)
__cpu_indicator_init ();
Richard.
>
> --
> H.J.
>