This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [arm] Fix arm_tune
- From: Richard Earnshaw <Richard dot Earnshaw at arm dot com>
- To: Paul Brook <paul at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Daniel Jacobowitz <drow at false dot org>
- Date: Wed, 21 Apr 2004 12:00:42 +0100
- Subject: Re: [arm] Fix arm_tune
- References: <200404202223.50097.paul@codesourcery.com>
On Tue, 2004-04-20 at 22:23, Paul Brook wrote:
> We currently set arm_tune incorrectly when the user specifies -march=. We were
> using indices of all_architectures as an index into all_codes.
>
> Patch below makes use the member added for this purpose.
>
> Tested with cross-compiler to arm-none-elf.
> Ok?
>
> Paul
>
> 2004-04-20 Paul Brook <paul@codesourcery.com>
>
> * config/arm/arm.c (all_cores): Set core.
> (arm_override_options): Set arm_tune to sel->core.
>
No, I don't think this is correct either.
Consider:
-march=armv4 -mtune=arm1136
Your patch will cause the tuning to be selected from the arch flag and
for -mtune to be ignored.
I need to think about this a bit (and don't have time at this minute).
I suspect we're missing a level of indirection that would allow us to
make the whole thing far more table driven. The idea would be to parse
all the options and use them to fill in a table ordered by preference,
then we pick the most preferred entry for each of the two targets.
So tuning would be ordered (possibly)
{-mtune, -mcpu, -march, --with-tune, --with-cpu, --with-arch}
while architecture might be ordered
{-march, -mcpu, --with-arch, --with-cpu, --mtune, --with-tune}
The final choice in each case is simply the first entry in each table
that is not NULL.
I'll get back to you.
R.