Re: [PATCH 7/14] [x86_64] Vector math functions (log and tests)

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 5 Jun 2015, Andrew Senkevich wrote:

> 2015-06-04 20:44 GMT+03:00 Joseph Myers <joseph@codesourcery.com>:
> > On Thu, 4 Jun 2015, Andrew Senkevich wrote:
> >
> >> This patch adds vector implementations of log for x86_64 and tests.
> >
> > I see this patch adds e.g. both _ZGVbN2v_log and _ZGVbN2v___log_finite, as
> > aliases.
> >
> > That's the sort of thing that needs specifically explaining in the patch
> > write-up.  In general, it's a bad idea to add extra interfaces to any of
> > glibc's shared libraries unless they actually have some sort of semantic
> > difference (or unless the interfaces are required to be usable without
> > including any headers) - and since all these vector functions are only for
> > -ffast-math, I don't think there is any semantic difference in the _finite
> > case.
> >
> > My guess is that this is something to do with interaction of the pragmas
> > that cause these functions to be used and the asm redirection of e.g. log
> > to __log_finite (for -ffinite-math-only, which is implied by -ffast-math).
> > Now, I suppose you do want that redirection to be in effect for calls that
> > don't get vectorized.  So I think you should try to work something out in
> > the compiler context as a way to say "vector calls should have their names
> > based on log not __log_finite, notwithstanding the redirection for scalar
> > calls", so we can avoid adding redundant ABIs to libmvec that are never
> > going to do anything different from the non-__*_finite ABIs.
> 
> Such aliases were added because GCC generates vector name based on
> scalar one already containing _finite redirection.
> May be stay only _ZGV*N*v___log_finite symbols?

How about having only the non-_finite symbols (which seems cleaner), with 
top-level __asm__ ("_ZGVbN2v___log_finite = _ZGVbN2v_log") etc. in the 
headers as a workaround until a conclusion is reached in the compiler 
context on a cleaner way to base the vector names on something other than 
the scalar asm name?

It's possible that in future we might have other scalar versions of some 
functions so the _finite version isn't the version selected for all 
functions with -ffast-math.  If so, I don't think we want to add more 
corresponding libmvec entry points - rather, work on getting a better 
solution in the compiler should start in parallel with getting the libmvec 
functions in using a workaround.

-- 
Joseph S. Myers
joseph@codesourcery.com