This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Consolidate and inline calls to __acr
- From: Steven Munroe <munroesj at linux dot vnet dot ibm dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, "Carlos O'Donell" <carlos at systemhalted dot org>, libc-alpha at sourceware dot org
- Date: Wed, 02 Jan 2013 14:03:44 -0600
- Subject: Re: [PATCH] Consolidate and inline calls to __acr
- References: <20121231134715.GD21621@spoyarek.pnq.redhat.com> <50E1AD98.email@example.com> <Pine.LNX.firstname.lastname@example.org> <20121231161323.GE21621@spoyarek.pnq.redhat.com>
- Reply-to: munroesj at us dot ibm dot com
On Mon, 2012-12-31 at 21:43 +0530, Siddhesh Poyarekar wrote:
> On Mon, Dec 31, 2012 at 04:00:50PM +0000, Joseph S. Myers wrote:
> > Regarding other targets, one thing I haven't seen mentioned in these
> > recent mpa.c patches is sysdeps/powerpc/powerpc32/power4/fpu/mpa.c and
> > sysdeps/powerpc/powerpc64/power4/fpu/mpa.c. I'm not sure why those files
> > exist and how they were originally different from the
> > architecture-independent versions, but do they need any updates to stay in
> > sync with the recent changes? Has the attention of the powerpc
> > maintainers been drawn to this patch series?
> Actually I haven't; I didn't notice that the mpa.c in power* were
> copies and not just macro definitions like the x86_64 ones. How about
> if I try to get rid of those files and then continue with the changes?
> If that's not possible, I'll at least try to macro'ize them like the
> x86_64 files.
I would disagree (as the original author of the powerpc specific
The source level loop unrolling in sysdeps/powerpc/powerpc[32|
64]/power4/fpu/mpa.c when combined with Makefile CFLAGS-mpa.c is similar
in kind to the ./x86_64/fpu/multiarch/[mpa-avx.c|mpa-fma4.c]
As such arbitrarily removing the powerpc implementation is not
appropriate. And just fixing the compile time error without
understanding the performance implications it not appropriate either.