This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ColdFire 9/63] Add -mcpu, -march, -mtune, and related options


Hi,

On Wed, 10 Jan 2007, Richard Sandiford wrote:

> So far, the m68k port has used separate -m options for each target,
> but having 60 separate -m options wasn't very appealing.  This patch
> therefore follows other ports by adding a -mcpu= option.  For consistency,
> it also adds an -march option to select an ISA by name and a -mtune option
> to tune for a specific microarchitecture.  m68k_handle_option maps the old
> -m options to a combination of these new ones.

I'm currently looking a bit closer at this and I'm a bit confused. These 
three new options make very little difference at least for the 680x0 part.
There is also a crucial difference now, -m680[346]0 don't produce the 
m68020 define anymore, which needs fixing, e.g. glibc uses it to enable 
68020 and higher features. The other m680[346]0 defines are less 
important, as I don't think there are used much, if at all (most m68k 
specific code was written for 2.95 or older which didn't produce these 
defines).

>From a 680x0 perspective I would prefer something closer to i386. -march 
would define the basic cpu architecture and the produced code wouldn't run 
on anything older. -mcpu/-mtune could be synonynous and specify the used 
cpu optimizations.
The TUNE_* macros may need a bit more work too. We have basically three 
classes:
- enable new cpu instructions
- enable cpu specific optimizations
- disable some (emulated) instructions
For example TUNE_68040 does the last two as soon as the 040 is somehow 
mentioned, but I'd prefer if -m68020-60 would actually not generate 040 
specific code sequences and just avoid the emulated instructions.

The question is now how ColdFire fits into this. I think something 
similiar could be done here by letting at least mcpu/mtune accept the same 
arguments or march could also accept cpu names and then imply a mtune 
option. I think the current interface is too complex, as the user needs 
detailed knowledge to figure out the best optimize options. Many current 
march/mcpu combinations conflict, where I wouldn't expect it and the 
different syntax from i386 isn't really helping.

bye, Roman


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]