This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Multiple versions of routines tuned for different devices
- From: Matthew Gretton-Dann <matthew dot gretton-dann at arm dot com>
- To: David Gilbert <david dot gilbert at linaro dot org>
- Cc: "newlib at sourceware dot org" <newlib at sourceware dot org>, Greta Yorsh <Greta dot Yorsh at arm dot com>
- Date: Tue, 15 Nov 2011 14:52:56 +0000
- Subject: Re: Multiple versions of routines tuned for different devices
- References: <CA+1XiSeyj1BmY4VTdzvtbwgSVs2bE+2K80jBcoEGrGxAdd2vmA@mail.gmail.com>
On 11/11/11 18:55, David Gilbert wrote:
Hi,
What's the right way to include multiple versions of string/memory
routines, where the appropriate
choice can't be determined from compiler defines?
Greta's memcpy for A15 ARMs is good, however I have a routine that
is faster on the older/current
A9 cores; I don't believe there is a way to get gcc to tell the code
what -mtune is passed to it.
Can we write some configure magic to look at how gcc is being invoked
and use that to create a pre-define?
So in configure scan "$(CC) $(CFLAGS)" for a -mtune option and use the
value of that to create an appropriate predefine.
If -mtune isn't in the command line, then for ARM EABI targets you could
compile a dummy file with -S to produce assembly output which will have
.cpu/.arch/.fpu directives present, and use those to set the predefine.
Then your source code would have to see which pre-defines were set to
determine which code to use, something like:
#ifdef __ARM_CORTEX_A15
/* Cortex-A15 implementation. */
#elif defined(__ARM_CORTEX_A9)
/* Cortex-A9 implementation. */
#else
/* Generic implementation. */
#endif
[The names __ARM_... in the compiler name-space so probably not the best
choices].
Thanks,
Matt
--
Matthew Gretton-Dann
Principal Engineer, PD Software - Tools, ARM Ltd