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

[Richard Sandiford <richard at codesourcery dot com>]

Roman Zippel <zippel@linux-m68k.org> writes:
> 4.1 has a TARGET_OS_CPP_BUILTINS in linux.h which defines it 
> unconditionally (so it's even defined with -m68000 :) ).

OK, feel free to add that back from my point of view.

I think what m68k.h itself now does is the same as what it used to do
(for the option combinations that were available in older compilers).
It sounds like you might disagree with that behaviour.  If so, feel free
to change it from my point of view: I don't have an opinion either way.
We already have a set of macros for ColdFire that provide the
architecture and tuning info we need.

>> However, that's a bikeshed thing, and I gather from recent discussions
>> that I was either misremembering the colour of the bikeshed at the
>> time that the MIPS options were implemented, or the colour has since
>> changed.
>
> Ok, I must have missed these discussions :), so I mostly go from what i386 
> does.

I meant off-list discussions, sorry.  It was being suggested that ARM
was the correct way for these things to be handled (and that, for example,
MIPS ought to have a -mcpu option.)

>> > 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.
>> 
>> To be clear, has the behaviour of -m68020-60 changed?  If so,
>> that was unintentional.
>
> I haven't really checked for this, since the new syntax allows for a few 
> more options, I'd rather concentrate on that.

OK, you snipped the next sentence that said: if you're thinking of
defining a new behaviour for 680x0, I have no opinion what's best.
I'll leave that discussion between you and the maintainers.
As far as implementation goes...

> I see two basic options:
> 1. We basically drop m68020-[46]0 and map it to TUNE_GENERIC instead.
> 2. We split m68k_tune into a separate m68k_tune_only and add a whole set 
> of TUNE_*_ONLY flags.
> I'd prefer the first option as it's simpler.

...I balk at the idea of having a m68k_tune_only. ;)

>> > 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.
>> 
>> Too complex in what situation?  The common case is simply to use
>> -mcpu=<my-cpu>.
>
> Well, that's the simple case, it gets more complicated if you want to 
> optimize for a range of cpus via march/mtune.

As far as I know, there was no intention of optimising for a _range_ of
ColdFire CPUs.

We only have single-processor -mtune settings on MIPS, and I've never
seen any complaints about that.  Trying to support -mtune settings for a
range of processors, making decisions that offset one against the other,
sounds far too complicated in general.  I realise that's what 68020-40
and 68020-60 do, but that's thankfully a small set.  (And it sounds like
there's doubt about what even those two combined tuning settings should
mean.)

> Since march and mcpu aren't really usable together I'd think we can do
> this with two options. Less options which are more flexible at what
> they accept would also be simpler to use IMO.

Well, I'm probably the wrong person to argue through that point with you.
Especially as I co-maintain a port with just such a set-up.  Maybe Nathan
(cc:ed) has comments.

Richard