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: David Gilbert <david dot gilbert at linaro dot org>
- To: Matthew Gretton-Dann <matthew dot gretton-dann at arm dot com>
- Cc: "newlib at sourceware dot org" <newlib at sourceware dot org>, Greta Yorsh <Greta dot Yorsh at arm dot com>
- Date: Tue, 29 Nov 2011 10:41:07 +0000
- Subject: Re: Multiple versions of routines tuned for different devices
- References: <CA+1XiSeyj1BmY4VTdzvtbwgSVs2bE+2K80jBcoEGrGxAdd2vmA@mail.gmail.com> <4EC27CC8.8020301@arm.com>
On 15 November 2011 14:52, Matthew Gretton-Dann
<matthew.gretton-dann@arm.com> wrote:
> 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.
I don't like the idea of scanning the flags - there are always weird ways people
manage to construct these (legally).
I prefer the idea of tweaking gcc to define it.
I kind of like Konrad's idea of modifying the spec file; however I suspect it
requires it being done in the .c code to deal with things like -mtune=native.
I think I'll ask on the gcc lists.
Dave