This is the mail archive of the
mailing list for the GCC project.
Re: PATCH: implement XScale scheduling
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Ben Elliston <bje at wasabisystems dot com>
- Cc: gcc-patches at gcc dot gnu dot org, ian at wasabisystems dot com, jim at wasabisystems dot com, Richard Earnshaw <rearnsha at arm dot com>
- Date: Sat, 13 Mar 2004 14:02:51 +0000
- Subject: Re: PATCH: implement XScale scheduling
- Organization: ARM Ltd.
- Reply-to: Richard Earnshaw <rearnsha at arm dot com>
> The following patch adds XScale-specific scheduling, particularly for
> the XScale multiplier pipeline. Benchmarks demonstated that
> scheduling the multiplication instructions can have an adverse effect
> on performance due to increased register pressure in the first
> scheduling pass. We opted to control multiplication instruction
> scheduling with a switch, -mxscale-schedule-mult.
> Tested on a NetBSD-x-xscale-elf cross-compiler, no regressions with or
> without the switch in use.
This is largely fine except for the issue of the extra flag.
I'm really not keen on adding a plethora of tuning flags -- my feeling is
that this feature should be either always on or always off. Whether or
not it is right to apply this flag will depend on subtle changes to the
compiler and to the user's source code. It's also the case that if a file
has two functions with a multiply one might benefit from having the flag
on while the other would benefit from it being off. That's certainly
likely to be true if you look at all the files in an application (which
will normally all be compiled with the same flags).
Register pressure created by the first scheduling pass is a serious
problem on the ARM due to the fairly limited number of registers, but I
don't really think this is the way to address the problem. It might be
worth looking at some of the work that has been done recently for SH
pre-register-allocation scheduling if you want to persue this problem
further. In the mean time I think you should pick one setting for the
compiler, stick with it and get rid of the flag.
On the patch itself, note that GCC now uses full ANSI function
declarations. You need to update your patch accordingly.