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

["Mark D. Baushke" <mdb at gnu dot org>]

> From: Richard Sandiford <rsandifo@redhat.com>
> 
> cgd@broadcom.com writes:
> > >    Question is, what are right values for _MIPS_ARCH and _MIPS_TUNE when
> > >    you use a generic ISA?  It doesn't seem right for them to name a
> > >    processor when the command line and configuration don't specify one.
> > 
> > I would advise simply going with whatever the processor is, unless
> > you're going to create 'real' entries for the arches
> > (e.g. _PROCESSOR_MIPS1.)
> 
> OK, if no-one jumps in, that's what I'll do.

I like the idea of 'real' entries for the known existing mips and
mips-like processors.

> > >    Not the biggest issue, I know, but is _MIPS_<foo> OK for the
> > >    processor macros?  I guess other alternatives would be
> > >    _MIPS_PROCESSOR_<foo> or _PROCESSOR_<foo>.
> > 
> > I'm for _PROCESSOR_*.
> 
> Others thought so too, so OK.

Sounds fine to me. I know of a few mips-like projects in the real world
that didn't get licensed by MTI for various reasons. No reason that they
should not be able to use this backend with some very minor tweaks to
synthesize any missing instructions or other minor differences...

> > I don't see why the values shouldn't change.
> > 
> > (1) The numbers aren't really meaningful.
> > 
> > (2) if used properly (as outlined in my message which spawned this
> >     particular feature), they'll all be resolved at compile time.

I do not know if I can say that (2) above is likely in the real world. A
LOT of folks use macros improperly and mix-and-match software that they
compile without understanding. It is the cross-compilation unit
integrity/abstractions that I suspect as being most vulnerable.

> > If there's a desire to record the values, e.g. for diagnostic output
> > from programs, that should probably be done using defines that use
> > strings.

Strings are nice. In a big memory machine, they are a fine thing to use.
When you have limited space they can be unfriendly, else why does the
-mips16 instruction set exist?

> Well, string macros are no problem, so I can add _MIPS_ARCH_STRING
> and _MIPS_TUNE_STRING.  If there really is no need for the macros
> to have guaranteed values, then there's obviously no need for a
> numbering convention, but...

Hmmm... yes, 'but...'

> > I've outlined (in off-list mail) a mechanism that would allow code to
> > check for specific CPUs being used in arch/tune which doesn't involve
> > any of this persistent, ad hoc numbering crud.  I think it's the right
> > way.
> > 
> > For the benefit of everybody else:
> > 
> > 	assume the processors _PROCESSOR_FOO and _PROCESSOR_BAR are
> > 	used by _MIPS_ARCH and _MIPS_TUNE
> > 
> > 	define _PROCESSOR_FOO the value 1.
> > 
> > 	iff FOO != BAR, define _PROCESSOR_BAR the value 2.
> > 
> > Since CPP math treats undefined values as 0, code like:
> > 
> > #if (_MIPS_ARCH == _PROCESSOR_LALALA)
> > 
> > will work properly, and code written as the example in my orignal
> > message:
> > 
> > 	switch (_MIPS_ARCH) {
> > #ifdef _PROCESSOR_LALALA
> > 	case _PROCESSOR_LALALA:
> > 		...
> > 		break;
> > #endif
> > 	default:
> > 		...
> > 		break;
> > 	}
> > 
> > will also work properly.
> > 
> > I believe that those are good examples of the style with which these
> > new defines should be used.

Hmmm... I think I see a problem with this, or at least it makes me
uneasy to make the assumption that users will code in the above manner.

If we presume that a user has built a library for a system and this
particular library was built with -march=foo -mtune=bar and is in place
a 'long' time such that the library users may have lost track as to what
it was tuned to do....

Now, time passes (say, the time between package mylibfoo is grabbed from
the net, built and installed and the time that mynewpkg (which is
dependent on mylibfoo) is also grabbed off the net, built and installed
with with -march=foo -mtune=baz as the default...

If the _PROCESSOR_FOO and _PROCESSOR_BAR and _PROCESSOR_BAZ do not hold
some long-term values, then it is possible for the _PROCESSOR_BAR to be
easily mis-used in the library and _PROCESSOR_BAZ misused in the
application to presume that they were both tuned for optimization in the
same way and/or for other assumptions to be made.

If the only examples of _PROCESSOR_BAR and _PROCESSOR_BAZ are in the
mylibfoo .h files, then there might be no problem, but if they are
spread around between mylibfoo and mynewpkg there is a potential for
trouble.

I agree that cgd's general proposal would work if everyone was very
careful... but I doubt the ability for careful consideration of this
kind of subtle idea to be well understood by general developers or by
folks that just grab and compile code from various sources without
regard for what flags are being passed to the compiler.

> 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)
>       ...
> 
> 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).

Yup. I see that problem as well.

> 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...

I see no reason that a number space could not be used, we still have the
potential problem where two divergent copies of gcc might add a new
processor to the list and not coordinate the conflict until much later,
so the macros will likely need to be mutable over time unless someone
wants to run a central registry. If the whole point of using
_PROCESSOR_<foo> instead of _MIPS_<foo> is to make sense, then we can
not count on MTI to keep the <foo> namespace or numberspace unique which
introduces another challenge...

> 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.
> 
> Richard

Well, the use of long strings that might show up multiple times in the
text or data segments of a program can be painful to the embedded world
who seems to always need more space to fit everything onto the device,
so care would be needed if that path was chosen to keep the names of
reasonable length if possible.

	-- Mark