Re: User directed Function Multiversioning via Function Overloading (issue5752064)

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Fri, May 25, 2012 at 5:16 PM, Sriraman Tallam <tmsriram@google.com> wrote:
> Hi H.J.,
>
> On Fri, May 25, 2012 at 5:07 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Mon, May 14, 2012 at 11:28 AM, Sriraman Tallam <tmsriram@google.com> wrote:
>>> Hi H.J,
>>>
>>> ? Attaching new patch with 2 test cases, mv2.C checks ISAs only and
>>> mv1.C checks ISAs and arches mixed. Right now, checking only arches is
>>> not needed as they are mutually exclusive, any order should be fine.
>>>
>>> Patch also available for review here: ?http://codereview.appspot.com/5752064
>>
>> Sorry for the delay. ?It looks OK except for the function order in tescases.
>> I think you should rearrange them so that they are not in the same order
>> as the priority.
>
> I am not sure I understand. The function order is mixed up in the
> declarations, I have explicitly commented about this. I only do the
> checking in order which I must, right?
>
>

gcc/testsuite/g++.dg/mv2.C has

int __attribute__ ((target("avx2")))
foo ()
{
  return 1;
}

int __attribute__ ((target("avx")))
foo ()
{
  return 2;
}

int __attribute__ ((target("popcnt")))
foo ()
{
  return 3;
}

int __attribute__ ((target("sse4.2")))
foo ()
{
  return 4;
}

int __attribute__ ((target("sse4.1")))
foo ()
{
  return 5;
}

int __attribute__ ((target("ssse3")))
foo ()
{
  return 6;
}

int __attribute__ ((target("sse3")))
foo ()
{
  return 7;
}

int __attribute__ ((target("sse2")))
foo ()
{
  return 8;
}

int __attribute__ ((target("sse")))
foo ()
{
  return 9;
}

int __attribute__ ((target("mmx")))
foo ()
{
  return 10;
}

It is most in the priority order.

BTW, I noticed:

[hjl@gnu-6 pr14170]$ readelf -sW libgcc.a | grep __cpu_model
    20: 0000000000000010    16 OBJECT  GLOBAL HIDDEN   COM __cpu_model
[hjl@gnu-6 pr14170]$ readelf -sW libgcc_s.so | grep __cpu_model
    82: 0000000000214ff0    16 OBJECT  GLOBAL DEFAULT   24
__cpu_model@@GCC_4.8.0
   310: 0000000000214ff0    16 OBJECT  GLOBAL DEFAULT   24 __cpu_model
[hjl@gnu-6 pr14170]$

Why is __cpu_model in both libgcc.a and libgcc_s.o?


H.J.