Re: [RFC] Add CPU feature bitmap to crt*

[Richard Guenther <rguenther at suse dot de>]

On Mon, 14 Nov 2005, Ian Lance Taylor wrote:

> Richard Guenther <rguenther@suse.de> writes:
> 
> > This is a prototype to add a runtime cpu feature detection for
> > versioning of target libraries and maybe user programs.  The Intel
> > compiler is providing __intel_cpu_indicator and 
> > __intel_cpu_indicator_init() (in libimf) for this purpose.  There
> > seems to be no sign of it supporting that as an official interface,
> > though, and such, it is undocumented.  For this reason, this prototype
> > patch does not try to expose the information apart from having the
> > __gcc_cpu_feature_indicator symbol visible.
> > 
> > Any thoughts?
> 
> A few:
> 
> * What's the goal?  If you want different target libraries on a
>   GNU/Linux system, it would presumably be more efficient to
>   dynamically link against the specific version for your host at run
>   time.

The goal is to enable both, different versions in libraries
(libgfortran and libm come to my mind), as well as the ability to
use automatic cpu dispatch in loop/function versioning, as the
Intel compiler currently does with the -a[WXMwhatever] switches.

> * So, I don't think this should be run at program startup time, but
>   should instead use a function interface.

I thought about adding an interface to the global 
program-startup-time-initialized information as f.i. 
__builtin_cpu_has_XXX_feature() or __builtin_cpu_has_feature(XXX).

> * Plus then the dynamic linker could pick a version which didn't have
>   to actually do any tests.

I'm not sure if this will work out.  For target libraries this may be
the way to go - in the end we may want to use versioning for different
cpus.  Of course this may need adjusting of the backend to support
generating code for different sub-models simultaneously.

> * I think this would be more useful if it were documented, which also
>   suggests a compiler internal header file that users can #include.

Of course.  The prototype was just to provoke some discussion and
ideas on the matter of targeting different subarchs.  Doing what
Intel does may be not the best technical solution to the problem.

Thanks,
Richard.