Re: [Revised patch] Rework MIPS command-line handling

[cgd@broadcom.com]

At 19 Jul 2002 09:36:11 +0100, Richard Sandiford wrote:
> It seems counter-intuitive to me that a condition written using '=='
> should only be usable in preprocessor statements.  Many style guides
> ask you to use C conditions instead of preprocessor ones, but you
> wouldn't be able to write:
> 
>     if (_MIPS_ARCH == _PROCESSOR_LALALA)
>       ...

Yes you would.  It would have to look the same as the switch, though:

#ifdef _PROCESSOR_LALALA
    if (_MIPS_ARCH == _PROCESSOR_LALALA
	...
#endif


> There's also the chance of subtle errors, like:
> 
>     int optimize_for = _MIPS_TUNE;
> 
> and, in another file, perhaps part of a library:
> 
>     switch (optimize_for)
>       {
> #ifdef _PROCESSOR_LALALA
>       case _PROCESSOR_LALALA:
> 	...
> #endif
>       }
> 
> OK, it obviously wouldn't be supported under the _MIPS_TUNE == 1 or 2
> scheme, but it would compile, and having '_MIPS_TUNE == FOO' conditions
> might just lead people to believe that _MIPS_TUNE can be treated as a
> regular number (like __mips or __mips_fpr can).

one of the cases would compile at least.  If done with the 'tune'
setting, it should be OK if slower.  If done with the arch setting, it
could be painful.

I think the moral of the story here is... programmers need to exercise
_some_ small bit of care when coding and compiling for
optimization...

I suspect that not defining most of the values most of the time would
keep people from making the really silly errors.


> The optimiser will (ought to?) remove redundant code, so why force
> the user to wrap each case in '#ifdef's?  Why not allow...
> 
>     switch (_MIPS_ARCH)
>       {
>       case _PROCESSOR_LALALA:
>         ...
>       }
>
> And if we define all the _PROCESSOR_FOO macros for each compilation
> unit, we might as well try to give them lasting values...

If you want to define all of the _PROCESSOR_FOO macros for each
compilation unit, i suppose that'll work, but I think that solution is
really quite lame.

It's a _whole_ bunch of completely unnecessary definitions, which do
nothing except add stuff to the command line which will be irrelevant
99.9% of the time.  I actually think this might make debugging (people
using gcc -v then running the steps independently) a fair bit more
annoying, too.

I don't think there are enough that you'll be in danger of running any
system out of command line argument space... but it really does seem
absurd.

If the desire is to have them consistently dfined, then they should be
put into a header file.


> If that idea really doesn't fly, I'd rather have _MIPS_ARCH
> be a string and define _MIPS_ARCH_FOO when compiling for FOO.

You know, now that you mention it, i think that might actually be the
best solution.  (kind of a "back to the future" thing, but with the
addition of a string for _MIPS_ARCH.  8-)



chris