This is the mail archive of the mailing list for the glibc 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: [RFC] How to add vector math functions to Glibc

On Wed, 24 Sep 2014, Andrew Senkevich wrote:

> Hi Joseph,
> >> > 1. Should functions go in libm or a separate libmvec library?
> >>
> >> If integrate new functions with libm it will be easier for developers
> >> to employ vectorization and should improve acceptance.
> >> Libmvec case affects compiler options and it seems new header need to
> >> be included instead of math.h, or is it OK include it in math.h?
> >> But libmvec could be better from the side of optional build (mentioned
> >> later in 2.) in case of addition most modern implementations.
> >
> > There is also the option of installing as a linker script that
> > refers to libmvec inside AS_NEEDED - is already a linker script
> > after all.  That way, libmvec would automatically be linked into programs
> > that need it (preserving compatibility with the POSIX rules about what
> > library names need specifying to get what functions), without restricting
> > the tools that can build glibc if vector extensions are added for which
> > tool support is recent, but building libmvec is optional.
> is it OK to have following changes in GLIBC build:

This patch doesn't seem to be relative to current sources.

> diff --git a/Makerules b/Makerules
> index 6b30e8c..058e748 100644
> --- a/Makerules
> +++ b/Makerules
> @@ -965,7 +965,22 @@ $(inst_libdir)/ $(common-objpfx) \
>        ' AS_NEEDED (' $(rtlddir)/$(rtld-installed-name) ') )' \
>   ) > $
>   mv -f $ $@
> -
> +else
> +ifeq ($(subdir),mathvect)
> +# We need to install as linker script
> +# for more comfortable use of libmvect library.

If consensus ends up being to have such a library (libmvec or libmvect?), 
then the installation rules for as a linker script should go in 
math/Makefile, not the toplevel Makerules.  (I don't know what if any 
changes might be needed to allow subdirectories to provide libraries as 
linker scripts.)

> diff --git a/shlib-versions b/shlib-versions
> index 40469bd..8fddc04 100644
> --- a/shlib-versions
> +++ b/shlib-versions
> @@ -35,6 +35,12 @@ sh.*-.*-linux.* libm=6 GLIBC_2.2
>  .*-.*-linux.* libm=6
>  .*-.*-gnu-gnu.* libm=6
> +# We provide starting from GLIBC_2.21 symbol set.
> +sparc64.*-.*-linux.* libmvect=1 GLIBC_2.21
> +sh.*-.*-linux.* libmvect=1 GLIBC_2.21
> +.*-.*-linux.* libmvect=1 GLIBC_2.21
> +.*-.*-gnu-gnu.* libmvect=1 GLIBC_2.21

No.  No architecture-specific or OS-specific content goes in 
shlib-versions outside the appropriate sysdeps directories any more, and 
shlib-versions no longer has a first column listing patterns matching 
configuration triplets.

Since the library will be architecture-specific, shlib-versions entries 
for its symbol versions would go in the relevant architecture files only 
when support is actually added for a given library.  But actually you 
don't need such entries, since each architecture will have Versions file 
entries for the symbols provided in this library on that architecture; 
symbol versions in shlib-versions only serve to override Versions files.  
So all you need is a single toplevel shlib-versions line to specify the 
SONAME.  That is, a line just saying


or similar.

Also, some configuration support will be needed to allow an architecture 
to specify (via its sysdeps configure fragments, I suppose) whether it 
supports this library at all, so builds for other architectures don't 
attempt to build it.  If not built, of course should remain as-is; 
it can't become a linker script referring to the new library.

Joseph S. Myers

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