[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

2021-09-17 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |6.0

--- Comment #26 from Andrew Pinski  ---
Fixed for GCC 6 by r6-4443.

https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Common-Function-Attributes.html#index-target_005fclones-function-attribute

[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

2018-01-18 Thread roland at rschulz dot eu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

Roland Schulz  changed:

   What|Removed |Added

 CC||roland at rschulz dot eu

--- Comment #25 from Roland Schulz  ---
I believe this can be closed because this has been implemented as target_clones
attribute.

[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

2014-05-26 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

--- Comment #22 from rguenther at suse dot de rguenther at suse dot de ---
On Sun, 25 May 2014, vincenzo.innocente at cern dot ch wrote:

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363
 
 vincenzo Innocente vincenzo.innocente at cern dot ch changed:
 
What|Removed |Added
 
 Version|4.7.0   |4.9.1
 
 --- Comment #21 from vincenzo Innocente vincenzo.innocente at cern dot ch 
 ---
 is Auto Cloning foreseen to be included anytime soon?
 It looks to me that it is not yet supported in gcc 4.9.0

It's supported in 4.9.0, but AFAIK only for x86 and C (or was it C++?).

Richard.


[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

2014-05-26 Thread vincenzo.innocente at cern dot ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

--- Comment #23 from vincenzo Innocente vincenzo.innocente at cern dot ch ---
Which Syntax?
I want to reuse the same code for the various architecture and let gcc deal
with vectorization details.
The best I manage to do to share code is something like this

namespace {
inline
float _sum0(float const *  x,
   float const *  y, float const *  z) {
  float sum=0;
  for (int i=0; i!=1024; ++i)
sum += z[i]+x[i]*y[i];
  return sum;
}
}


float  __attribute__ ((__target__ (arch=haswell)))
sum1(float const *  x,
 float const *  y, float const *  z) {
  return _sum0(x,y,z);
}

float  __attribute__ ((__target__ (arch=nehalem)))
sum1(float const *  x,
 float const *  y, float const *  z) {
  return _sum0(x,y,z);
}

//--

this for instance does not work (produce code only for haswell)

float  __attribute__ ( (__target__(arch=nehalem), __target__(arch=haswell))
)
sum0(float const *  x,
  float const *  y, float const *  z) {
 float sum=0;
 for (int i=0; i!=1024; ++i)
   sum += z[i]+x[i]*y[i];
 return sum;
}


[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

2014-05-26 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

--- Comment #24 from rguenther at suse dot de rguenther at suse dot de ---
On Mon, 26 May 2014, vincenzo.innocente at cern dot ch wrote:

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363
 
 --- Comment #23 from vincenzo Innocente vincenzo.innocente at cern dot ch 
 ---
 Which Syntax?
 I want to reuse the same code for the various architecture and let gcc deal
 with vectorization details.
 The best I manage to do to share code is something like this
 
 namespace {
 inline
 float _sum0(float const *  x,
float const *  y, float const *  z) {
   float sum=0;
   for (int i=0; i!=1024; ++i)
 sum += z[i]+x[i]*y[i];
   return sum;
 }
 }
 
 
 float  __attribute__ ((__target__ (arch=haswell)))
 sum1(float const *  x,
  float const *  y, float const *  z) {
   return _sum0(x,y,z);
 }
 
 float  __attribute__ ((__target__ (arch=nehalem)))
 sum1(float const *  x,
  float const *  y, float const *  z) {
   return _sum0(x,y,z);
 }

I think that's the desired interface (it was designed with the
expectation you'd use intrinsics in the special functions, not
simply let the autovectorizer do its work IIRC).


[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

2014-05-25 Thread vincenzo.innocente at cern dot ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

vincenzo Innocente vincenzo.innocente at cern dot ch changed:

   What|Removed |Added

Version|4.7.0   |4.9.1

--- Comment #21 from vincenzo Innocente vincenzo.innocente at cern dot ch ---
is Auto Cloning foreseen to be included anytime soon?
It looks to me that it is not yet supported in gcc 4.9.0


[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

2012-05-10 Thread vincenzo.innocente at cern dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

--- Comment #17 from vincenzo Innocente vincenzo.innocente at cern dot ch 
2012-05-10 10:16:13 UTC ---
I tested this

float x[1024], y[1024], z[1024], w[1024];

void foo() {
  for (int i=0; i!=1024; ++i)
 x[i]=y[i]*z[i]+w[i];
}


void __attribute__ ((target(arch=corei7))) foo() {
  for (int i=0; i!=1024; ++i)
 x[i]=y[i]*z[i]+w[i];
}

void __attribute__ ((target(avx))) foo() {
  for (int i=0; i!=1024; ++i)
 x[i]=y[i]*z[i]+w[i];
}


and see the three versions generated  + the resolver.

As you notice the source code is identical as I'm exploiting compiler
autovectorization here.
In this case I was hoping that a single declaration such as  __attribute__
((target(arch=corei7,avx)))
or  __attribute__ ((target(arch=corei7),target(avx))) would generate the two
versions w/o hang to duplicate the source code.
Is this possible to support?


[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

2012-05-10 Thread tmsriram at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

--- Comment #18 from Sriraman Tallam tmsriram at google dot com 2012-05-10 
16:48:45 UTC ---
On Thu, May 10, 2012 at 3:16 AM, vincenzo.innocente at cern dot ch
gcc-bugzi...@gcc.gnu.org wrote:
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

 --- Comment #17 from vincenzo Innocente vincenzo.innocente at cern dot ch 
 2012-05-10 10:16:13 UTC ---
 I tested this

 float x[1024], y[1024], z[1024], w[1024];

 void foo() {
  for (int i=0; i!=1024; ++i)
     x[i]=y[i]*z[i]+w[i];
 }


 void __attribute__ ((target(arch=corei7))) foo() {
  for (int i=0; i!=1024; ++i)
     x[i]=y[i]*z[i]+w[i];
 }

 void __attribute__ ((target(avx))) foo() {
  for (int i=0; i!=1024; ++i)
     x[i]=y[i]*z[i]+w[i];
 }


 and see the three versions generated  + the resolver.

 As you notice the source code is identical as I'm exploiting compiler
 autovectorization here.
 In this case I was hoping that a single declaration such as  __attribute__
 ((target(arch=corei7,avx)))
 or  __attribute__ ((target(arch=corei7),target(avx))) would generate the 
 two
 versions w/o hang to duplicate the source code.
 Is this possible to support?

Yes, this is on the list of things to add. The front-end should clone
the bodies and tag the attributes appropriately.

Thanks,
-Sri,



 --
 Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
 --- You are receiving this mail because: ---
 You are on the CC list for the bug.


[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

2012-05-10 Thread vincenzo.innocente at cern dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

--- Comment #19 from vincenzo Innocente vincenzo.innocente at cern dot ch 
2012-05-10 16:51:33 UTC ---
On 10 May, 2012, at 6:48 PM, tmsriram at google dot com wrote:

 As you notice the source code is identical as I'm exploiting compiler
 autovectorization here.
 In this case I was hoping that a single declaration such as  __attribute__
 ((target(arch=corei7,avx)))
 or  __attribute__ ((target(arch=corei7),target(avx))) would generate the 
 two
 versions w/o hang to duplicate the source code.
 Is this possible to support?
 
 Yes, this is on the list of things to add. The front-end should clone
 the bodies and tag the attributes appropriately.
 
good.
Let me know when available, I wil test it with even longer code!

v.


 Thanks,
 -Sri,


[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

2012-05-10 Thread xinliangli at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

--- Comment #20 from davidxl xinliangli at gmail dot com 2012-05-10 20:45:58 
UTC ---
Auto Cloning is an independent feature. What is requested here is an extension
of a previous auto clone patch by Sri (which is based on command line option
-mversion=...).

David


(In reply to comment #18)
 On Thu, May 10, 2012 at 3:16 AM, vincenzo.innocente at cern dot ch
 gcc-bugzi...@gcc.gnu.org wrote:
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363
 
  --- Comment #17 from vincenzo Innocente vincenzo.innocente at cern dot ch 
  2012-05-10 10:16:13 UTC ---
  I tested this
 
  float x[1024], y[1024], z[1024], w[1024];
 
  void foo() {
   for (int i=0; i!=1024; ++i)
      x[i]=y[i]*z[i]+w[i];
  }
 
 
  void __attribute__ ((target(arch=corei7))) foo() {
   for (int i=0; i!=1024; ++i)
      x[i]=y[i]*z[i]+w[i];
  }
 
  void __attribute__ ((target(avx))) foo() {
   for (int i=0; i!=1024; ++i)
      x[i]=y[i]*z[i]+w[i];
  }
 
 
  and see the three versions generated  + the resolver.
 
  As you notice the source code is identical as I'm exploiting compiler
  autovectorization here.
  In this case I was hoping that a single declaration such as  __attribute__
  ((target(arch=corei7,avx)))
  or  __attribute__ ((target(arch=corei7),target(avx))) would generate the 
  two
  versions w/o hang to duplicate the source code.
  Is this possible to support?
 
 Yes, this is on the list of things to add. The front-end should clone
 the bodies and tag the attributes appropriately.
 
 Thanks,
 -Sri,
 
 
 
  --
  Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
  --- You are receiving this mail because: ---
  You are on the CC list for the bug.


[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

2012-05-09 Thread tmsriram at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

--- Comment #16 from Sriraman Tallam tmsriram at google dot com 2012-05-09 
19:03:01 UTC ---
Bug fixed, patch here: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00694.html

Thanks for trying,
-Sri.


On Tue, May 8, 2012 at 2:18 AM, vincenzo.innocente at cern dot ch
gcc-bugzi...@gcc.gnu.org wrote:
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

 --- Comment #14 from vincenzo Innocente vincenzo.innocente at cern dot ch 
 2012-05-08 09:18:01 UTC ---
 added your patch on top of
 c++ -v
 Using built-in specs.
 COLLECT_GCC=c++
 COLLECT_LTO_WRAPPER=/afs/cern.ch/user/i/innocent/w2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
 Target: x86_64-unknown-linux-gnu
 Configured with: ./configure --prefix=/afs/cern.ch/user/i/innocent/w2
 --enable-languages=c,c++,fortran -enable-gold=yes --enable-lto
 --with-build-config=bootstrap-lto --with-gmp-lib=/usr/local/lib64
 --with-mpfr-lib=/usr/local/lib64 -with-mpc-lib=/usr/local/lib64
 --enable-cloog-backend=isl --with-cloog=/usr/local
 --with-ppl-lib=/usr/local/lib64 CFLAGS='-O2 -ftree-vectorize -fPIC'
 CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden 
 -march=native'
 -enable-libitm -disable-multilib : (reconfigured) ./configure
 --prefix=/afs/cern.ch/user/i/innocent/w2 -enable-gold=yes --enable-lto
 --with-build-config=bootstrap-lto --with-gmp-lib=/usr/local/lib64
 --with-mpfr-lib=/usr/local/lib64 -with-mpc-lib=/usr/local/lib64
 --enable-cloog-backend=isl --with-cloog=/usr/local
 --with-ppl-lib=/usr/local/lib64 CFLAGS='-O2 -ftree-vectorize -fPIC'
 CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden 
 -march=native'
 -enable-libitm -disable-multilib CC=gcc CXX=g++
 --enable-languages=c,c++,fortran,lto --no-create --no-recursion
 Thread model: posix
 gcc version 4.8.0 20120508 (experimental) [trunk revision 187276] (GCC)

 configured as above

 ad got

 ../.././gcc/multiversion.c:613: error: undefined reference to
 'cgraph_add_to_same_comdat_group'
 collect2: ld returned 1 exit status
 make[3]: *** [lto1] Error 1
 make[3]: *** Waiting for unfinished jobs
 ../.././gcc/multiversion.c:613: error: undefined reference to
 'cgraph_add_to_same_comdat_group'
 collect2: ld returned 1 exit status
 make[3]: *** [cc1] Error 1
 ../.././gcc/multiversion.c:613: error: undefined reference to
 'cgraph_add_to_same_comdat_group'
 collect2: ld returned 1 exit status
 make[3]: *** [cc1plus] Error 1
 rm gcov.pod cpp.pod gfdl.pod fsf-funding.pod gcc.pod
 make[3]: Leaving directory
 `/home/data/newsoft/gcc-trunk/host-x86_64-unknown-linux-gnu/gcc'
 make[2]: *** [all-stage1-gcc] Error 2
 make[2]: Leaving directory `/home/data/newsoft/gcc-trunk'
 make[1]: *** [stage1-bubble] Error 2
 make[1]: Leaving directory `/home/data/newsoft/gcc-trunk'
 make: *** [all] Error 2

 --
 Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
 --- You are receiving this mail because: ---
 You are on the CC list for the bug.


[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

2012-05-08 Thread vincenzo.innocente at cern dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

--- Comment #14 from vincenzo Innocente vincenzo.innocente at cern dot ch 
2012-05-08 09:18:01 UTC ---
added your patch on top of
c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/afs/cern.ch/user/i/innocent/w2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/afs/cern.ch/user/i/innocent/w2
--enable-languages=c,c++,fortran -enable-gold=yes --enable-lto
--with-build-config=bootstrap-lto --with-gmp-lib=/usr/local/lib64
--with-mpfr-lib=/usr/local/lib64 -with-mpc-lib=/usr/local/lib64
--enable-cloog-backend=isl --with-cloog=/usr/local
--with-ppl-lib=/usr/local/lib64 CFLAGS='-O2 -ftree-vectorize -fPIC'
CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden -march=native'
-enable-libitm -disable-multilib : (reconfigured) ./configure
--prefix=/afs/cern.ch/user/i/innocent/w2 -enable-gold=yes --enable-lto
--with-build-config=bootstrap-lto --with-gmp-lib=/usr/local/lib64
--with-mpfr-lib=/usr/local/lib64 -with-mpc-lib=/usr/local/lib64
--enable-cloog-backend=isl --with-cloog=/usr/local
--with-ppl-lib=/usr/local/lib64 CFLAGS='-O2 -ftree-vectorize -fPIC'
CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden -march=native'
-enable-libitm -disable-multilib CC=gcc CXX=g++
--enable-languages=c,c++,fortran,lto --no-create --no-recursion
Thread model: posix
gcc version 4.8.0 20120508 (experimental) [trunk revision 187276] (GCC) 

configured as above

ad got

../.././gcc/multiversion.c:613: error: undefined reference to
'cgraph_add_to_same_comdat_group'
collect2: ld returned 1 exit status
make[3]: *** [lto1] Error 1
make[3]: *** Waiting for unfinished jobs
../.././gcc/multiversion.c:613: error: undefined reference to
'cgraph_add_to_same_comdat_group'
collect2: ld returned 1 exit status
make[3]: *** [cc1] Error 1
../.././gcc/multiversion.c:613: error: undefined reference to
'cgraph_add_to_same_comdat_group'
collect2: ld returned 1 exit status
make[3]: *** [cc1plus] Error 1
rm gcov.pod cpp.pod gfdl.pod fsf-funding.pod gcc.pod
make[3]: Leaving directory
`/home/data/newsoft/gcc-trunk/host-x86_64-unknown-linux-gnu/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/home/data/newsoft/gcc-trunk'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/data/newsoft/gcc-trunk'
make: *** [all] Error 2


[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

2012-05-08 Thread tmsriram at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

--- Comment #15 from Sriraman Tallam tmsriram at google dot com 2012-05-08 
17:09:43 UTC ---
On Tue, May 8, 2012 at 2:18 AM, vincenzo.innocente at cern dot ch
gcc-bugzi...@gcc.gnu.org wrote:
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

 --- Comment #14 from vincenzo Innocente vincenzo.innocente at cern dot ch 
 2012-05-08 09:18:01 UTC ---
 added your patch on top of
 c++ -v
 Using built-in specs.
 COLLECT_GCC=c++
 COLLECT_LTO_WRAPPER=/afs/cern.ch/user/i/innocent/w2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
 Target: x86_64-unknown-linux-gnu
 Configured with: ./configure --prefix=/afs/cern.ch/user/i/innocent/w2
 --enable-languages=c,c++,fortran -enable-gold=yes --enable-lto
 --with-build-config=bootstrap-lto --with-gmp-lib=/usr/local/lib64
 --with-mpfr-lib=/usr/local/lib64 -with-mpc-lib=/usr/local/lib64
 --enable-cloog-backend=isl --with-cloog=/usr/local
 --with-ppl-lib=/usr/local/lib64 CFLAGS='-O2 -ftree-vectorize -fPIC'
 CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden 
 -march=native'
 -enable-libitm -disable-multilib : (reconfigured) ./configure
 --prefix=/afs/cern.ch/user/i/innocent/w2 -enable-gold=yes --enable-lto
 --with-build-config=bootstrap-lto --with-gmp-lib=/usr/local/lib64
 --with-mpfr-lib=/usr/local/lib64 -with-mpc-lib=/usr/local/lib64
 --enable-cloog-backend=isl --with-cloog=/usr/local
 --with-ppl-lib=/usr/local/lib64 CFLAGS='-O2 -ftree-vectorize -fPIC'
 CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden 
 -march=native'
 -enable-libitm -disable-multilib CC=gcc CXX=g++
 --enable-languages=c,c++,fortran,lto --no-create --no-recursion
 Thread model: posix
 gcc version 4.8.0 20120508 (experimental) [trunk revision 187276] (GCC)

 configured as above

 ad got

 ../.././gcc/multiversion.c:613: error: undefined reference to
 'cgraph_add_to_same_comdat_group'
 collect2: ld returned 1 exit status
 make[3]: *** [lto1] Error 1
 make[3]: *** Waiting for unfinished jobs
 ../.././gcc/multiversion.c:613: error: undefined reference to
 'cgraph_add_to_same_comdat_group'

Thanks, I will fix this asap.

 collect2: ld returned 1 exit status
 make[3]: *** [cc1] Error 1
 ../.././gcc/multiversion.c:613: error: undefined reference to
 'cgraph_add_to_same_comdat_group'
 collect2: ld returned 1 exit status
 make[3]: *** [cc1plus] Error 1
 rm gcov.pod cpp.pod gfdl.pod fsf-funding.pod gcc.pod
 make[3]: Leaving directory
 `/home/data/newsoft/gcc-trunk/host-x86_64-unknown-linux-gnu/gcc'
 make[2]: *** [all-stage1-gcc] Error 2
 make[2]: Leaving directory `/home/data/newsoft/gcc-trunk'
 make[1]: *** [stage1-bubble] Error 2
 make[1]: Leaving directory `/home/data/newsoft/gcc-trunk'
 make: *** [all] Error 2

 --
 Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
 --- You are receiving this mail because: ---
 You are on the CC list for the bug.


[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

2012-05-07 Thread vincenzo.innocente at cern dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

--- Comment #11 from vincenzo Innocente vincenzo.innocente at cern dot ch 
2012-05-07 13:05:18 UTC ---
Please post on this PR when a version of 4.8 exists that supports the feature 
(I saw several patches proposed and even committed)


[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

2012-05-07 Thread tmsriram at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

--- Comment #12 from Sriraman Tallam tmsriram at google dot com 2012-05-07 
16:54:57 UTC ---
Will do, thanks.

-Sri.

On Mon, May 7, 2012 at 6:05 AM, vincenzo.innocente at cern dot ch
gcc-bugzi...@gcc.gnu.org wrote:
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

 --- Comment #11 from vincenzo Innocente vincenzo.innocente at cern dot ch 
 2012-05-07 13:05:18 UTC ---
 Please post on this PR when a version of 4.8 exists that supports the feature
 (I saw several patches proposed and even committed)

 --
 Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
 --- You are receiving this mail because: ---
 You are on the CC list for the bug.


[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

2012-05-07 Thread tmsriram at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

--- Comment #13 from Sriraman Tallam tmsriram at google dot com 2012-05-07 
17:04:05 UTC ---
Here is the patch to do function multiversioning which is under review:
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00078.html


[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

2011-10-28 Thread vincenzo.innocente at cern dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

--- Comment #7 from vincenzo Innocente vincenzo.innocente at cern dot ch 
2011-10-28 09:06:30 UTC ---
sorry to ping again.
Stage 1 is supposed to end Nov 7th.
Will the new feature work out by Sri make for 4.7?


[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

2011-10-28 Thread rguenther at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

--- Comment #8 from rguenther at suse dot de rguenther at suse dot de 
2011-10-28 09:14:29 UTC ---
On Fri, 28 Oct 2011, vincenzo.innocente at cern dot ch wrote:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363
 
 --- Comment #7 from vincenzo Innocente vincenzo.innocente at cern dot ch 
 2011-10-28 09:06:30 UTC ---
 sorry to ping again.
 Stage 1 is supposed to end Nov 7th.
 Will the new feature work out by Sri make for 4.7?

No


[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

2011-10-28 Thread vincenzo.innocente at cern dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

--- Comment #9 from vincenzo Innocente vincenzo.innocente at cern dot ch 
2011-10-28 14:00:18 UTC ---
That's a pity.
It would be very useful though to have at least a patch to test so that we can
have something to use in prototypes and eventually a working solution for 4.8


[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

2011-10-28 Thread tmsriram at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

--- Comment #10 from Sriraman Tallam tmsriram at google dot com 2011-10-28 
17:28:23 UTC ---
On Fri, Oct 28, 2011 at 7:00 AM, vincenzo.innocente at cern dot ch
gcc-bugzi...@gcc.gnu.org wrote:
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

 --- Comment #9 from vincenzo Innocente vincenzo.innocente at cern dot ch 
 2011-10-28 14:00:18 UTC ---
 That's a pity.
 It would be very useful though to have at least a patch to test so that we can
 have something to use in prototypes and eventually a working solution for 4.8

Still working on it. Will keep you posted as soon as I have a patch to test.


 --
 Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
 --- You are receiving this mail because: ---
 You are on the CC list for the bug.



[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

2011-07-23 Thread vincenzo.innocente at cern dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

--- Comment #5 from vincenzo Innocente vincenzo.innocente at cern dot ch 
2011-07-23 13:29:36 UTC ---
Any news on this item? 
Is this feature still foreseen for 4.7?
A patch to test for instance.


[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

2011-07-23 Thread xinliangli at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

--- Comment #6 from davidxl xinliangli at gmail dot com 2011-07-23 17:28:30 
UTC ---
(In reply to comment #5)
 Any news on this item? 
 Is this feature still foreseen for 4.7?
 A patch to test for instance.

Sri is working on this. He will post a formal specification of feature soon.
Part of the proposal also includes implementation of the MV runtime support
(runtime initialization to determine cpu topology and intrinsics to query) and
command line option extensions.  

David


[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

2011-06-11 Thread vincenzo.innocente at cern dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

--- Comment #2 from vincenzo Innocente vincenzo.innocente at cern dot ch 
2011-06-11 05:58:46 UTC ---
These new developments sound interesting. Hope somebody is working on it and
will publish a testable version soon.
On the other hand I was thinking more of exploiting auto-vectorization for
which having multiple copy of the very same code looks to me not necessary and
error prone, Something for instance along these line
float  __attribute__ ((__target__ (sse2,sse3,avx,fma))) 
sum0(float const * __restrict__ x, 
   float const * __restrict__ y, float const * __restrict__ z) {
  float sum=0;
  for (int i=0; i!=1024; ++i)
sum += z[i]+x[i]*y[i];
  return sum;
}

If my understanding of the proposal is correct I will have to copy-paste this
function four times, one for each target.


[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

2011-06-11 Thread xinliangli at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

davidxl xinliangli at gmail dot com changed:

   What|Removed |Added

 CC||tmsriram at google dot com

--- Comment #3 from davidxl xinliangli at gmail dot com 2011-06-11 06:23:21 
UTC ---
(In reply to comment #2)
 These new developments sound interesting. Hope somebody is working on it and
 will publish a testable version soon.
 On the other hand I was thinking more of exploiting auto-vectorization for
 which having multiple copy of the very same code looks to me not necessary and
 error prone, Something for instance along these line
 float  __attribute__ ((__target__ (sse2,sse3,avx,fma))) 
 sum0(float const * __restrict__ x, 
float const * __restrict__ y, float const * __restrict__ z) {
   float sum=0;
   for (int i=0; i!=1024; ++i)
 sum += z[i]+x[i]*y[i];
   return sum;
 }
 
 If my understanding of the proposal is correct I will have to copy-paste this
 function four times, one for each target.



The overloading proposal works for both manual versioning and automatic
versioning.

For manual versioning:

// generic version
void foo() 
{

}

void foo() __attribute((dispatch_selector(v1))
{

}

void foo() __attribute((dispatch_selector(v2))
{

}

void bar()
{
   foo();   --- becomes a three way dispatching 

...
}

Here both the version and dispatcher ARE defined by the user. 

 However, without specifying any attribute for the generic version of foo, the
compiler can also version it automatically according to command line option
that specifies the target hardwares the binary is going to be run.


For your case, the standard CPU feature is specified,

void __attribute__((__target__(sse2, avx, fma)) foo ()
{ ... }

it is the same as the auto version case mentioned above -- the difference is
that the function to be versioned is determined by the user, not the compiler.


David


[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

2011-06-11 Thread vincenzo.innocente at cern dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

--- Comment #4 from vincenzo Innocente vincenzo.innocente at cern dot ch 
2011-06-11 07:06:24 UTC ---
Thanks for the clarification, waiting for some patch/branch to test.
please keep me posted (or let me know with PR I shall watch).


[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

2011-06-10 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.10 12:42:03
 CC||dnovillo at gcc dot
   ||gnu.org, rguenth at gcc dot
   ||gnu.org, xinliangli at
   ||gmail dot com
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-10 
12:42:03 UTC ---
See the thread starting at
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02285.html
(continuing in May).  Eventually we agreed that the user-side could be
done by a kind of function overload resolution of properly tagged functions
(proposed in http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00150.html).

No idea if there is anybody working on it.