On Wed, 13 Mar 2019, Richard Biener wrote:
> And that fortran support patch would need yet another iteration.
Fortran never uses the _finite names because it never uses the C header
that can declare the functions to use those asm names.
--
Joseph S. Myers
jos...@codesourcery.com
On Wed, 2019-03-13 at 14:38 +, Joseph Myers wrote:
>
> ---
> ---
> On Wed, 13 Mar 2019, Jakub Jelinek wrote:
>
> > If the finite only doesn't buy anything, then another option is to drop the
> > math-finite.h stuff or portions
On Wed, 13 Mar 2019, Jakub Jelinek wrote:
> If the finite only doesn't buy anything, then another option is to drop the
> math-finite.h stuff or portions thereof.
Well, finite-only entry points avoid wrappers for the scalar functions -
it's just that suitable optimized implementations could
On Wed, Mar 13, 2019 at 02:07:29PM +0100, Jakub Jelinek wrote:
> On Wed, Mar 13, 2019 at 01:00:58PM +, Joseph Myers wrote:
> > > Yeah, an alias doesn't really cost much, and has the advantage that if in
> > > the vector version you need at some point to differentiate between the
> > > finite
On Wed, Mar 13, 2019 at 01:00:58PM +, Joseph Myers wrote:
> > Yeah, an alias doesn't really cost much, and has the advantage that if in
> > the vector version you need at some point to differentiate between the
> > finite only vs. full implementations, you can just by tweaking libmvec
> >
On Wed, 13 Mar 2019, Jakub Jelinek wrote:
> Yeah, an alias doesn't really cost much, and has the advantage that if in
> the vector version you need at some point to differentiate between the
> finite only vs. full implementations, you can just by tweaking libmvec
> implementation, the callers
On Wed, Mar 13, 2019 at 01:01:54PM +0100, Richard Biener wrote:
> On Wed, Mar 13, 2019 at 12:40 AM Jakub Jelinek wrote:
> >
> > On Tue, Mar 12, 2019 at 11:21:26PM +, Steve Ellcey wrote:
> > > I like this idea. I have prototyped something, I created 'vector_asm'
> > > as an aarch64 attribute
On Wed, Mar 13, 2019 at 12:40 AM Jakub Jelinek wrote:
>
> On Tue, Mar 12, 2019 at 11:21:26PM +, Steve Ellcey wrote:
> > I like this idea. I have prototyped something, I created 'vector_asm'
> > as an aarch64 attribute because I couldn't find where to put global
> > attributes like __simd__.
On Tue, Mar 12, 2019 at 11:21:26PM +, Steve Ellcey wrote:
> I like this idea. I have prototyped something, I created 'vector_asm'
> as an aarch64 attribute because I couldn't find where to put global
> attributes like __simd__. Does anyone know where these are listed?
On Tue, 2019-03-12 at 14:17 +, Joseph Myers wrote:
>
> On Tue, 12 Mar 2019, Richard Biener wrote:
>
> > It shouldn't be difficult to provide an alias from the glibc side, no?
> > How does x86 avoid this issue?
>
> There are static-only wrappers in libmvec_nonshared.a to work around the
>
On Tue, 12 Mar 2019, Richard Biener wrote:
> It shouldn't be difficult to provide an alias from the glibc side, no?
> How does x86 avoid this issue?
There are static-only wrappers in libmvec_nonshared.a to work around the
GCC limitation (not included in the shared library, so less efficient
On Tue, Mar 12, 2019 at 09:33:40AM +0100, Jakub Jelinek wrote:
> On Tue, Mar 12, 2019 at 09:25:35AM +0100, Richard Biener wrote:
> > I think this needs to be fixed on the glibc side - if glibc advertises
> >
> > float expf (float, float)
> >
On Tue, Mar 12, 2019 at 09:25:35AM +0100, Richard Biener wrote:
> I think this needs to be fixed on the glibc side - if glibc advertises
>
> float expf (float, float)
> __attribute__((simd(notinbranch),alias("__expf_finite"))
>
> or so then you of course have to provide an implementation that
On Mon, Mar 11, 2019 at 11:39 PM Steve Ellcey wrote:
>
> This is a proposed GCC patch that allows targets to modify the names of
> the libmvec routines that get called. Currently, if you build ToT GCC
> on Aarch64 and include this glibc patch:
>
>
14 matches
Mail list logo
