Re: Add sh4a support to the SH port

[amylaar at spamcop dot net (Joern Rennecke)]

> FWIW, I originally had separate multilibs for all m4a variants, just
> like we do for SH4, but I thought it was mostly overkill and changed

Actually, -m4-nofpu is not included in the vanilla sh-elf configuration -
-m2 is used there instead.  The sh-superh-elf configuration has an
sh4-elf-nofpu multilib by default, though.

> my mind just before contributing the patch.  This would solve the
> problem, at the expense of significant build time and disk space
> increase.  Would you mind that?

> FWIW, I'm about to contribute SH2a support, and that brings in the
> need for at least two new multilibs, and possibly 4 if we refrain from
> using SH2 libs for -m2a and SH2e for -m2a-single-only.  Comments?

Please, don't add gratitouisly new multilibs to the sh-elf configuration
defaults.  Build times are bad enough as it is.
For cache coherency we really need only a single function to be build
differently, and that can be solved with the libicache*.a library mechanism.

Note, if you just want to tune for a particular processor, you can use
the --with-multilib-list configuration option to justomize the multilibs
that are built.  If a particular list is useful enough for a group of people,
we can add a new configuration name as a shortcut.