Re: [PATCH, MIPS] Add Octeon target

[Richard Sandiford <rdsandiford at googlemail dot com>]

Adam Nemet <anemet@caviumnetworks.com> writes:
> 	* config.gcc (mips64*-*-linux*): Handle mips64octeon*-*-linux*.
> 	* config/mips/mips.h (enum processor_type): Add PROCESSOR_OCTEON.
> 	(TARGET_OCTEON): New macro.
> 	(TARGET_CPU_CPP_BUILTINS): Define __OCTEON__ for Octeon.
> 	(MIPS_ISA_LEVEL_SPEC, MIPS_ARCH_FLOAT_SPEC): Handle -march=octeon.
> 	(ISA_HAS_POP): New macro.
> 	* config/mips/driver-native.c (host_detect_local_cpu): Handle
> 	Octeon.
> 	* config/mips/mips.c (mips_cpu_info_table, mips_rtx_cost_data):
> 	Handle Octeon.
> 	* config/mips/mips.md (cpu): Add octeon.
> 	(type): Add pop attribute value.
> 	(popcount<mode>2): New pattern.
> 	* doc/invoke.texi (-march=@var{arch}): Add octeon.
> testsuite/
> 	* gcc.target/mips/octeon-pop-1.c: New test.

OK, thanks.  I agree with David that adding new processor-specific
configurations is a concern in cases where the choice of processor
is the only change.  But given what you said in the follow-up,
a new configuration does seem justified.

Regarding gas and -msoft-float: I'm no longer sure of what I said here:

    http://sourceware.org/ml/binutils/2008-02/msg00189.html

While I agree that using GAS directives is the safest and most direct of
communicating the architecture between cc1 and GAS, we really do want
hand-written assembly input to be assembled in the same way as
compiler-generated input.  So I'm falling back to saying that we
should use driver specs, just like we do for -march and -mabi selection.

In this case, maybe the best way of forcing -msoft-float onto the driver
command line by adding something like:

    with_float=${with_float:-soft}

to the mips64*-octeon* config.gcc stanza.  (Doesn't need to be part
of this patch.)  Then, as you said in the follow-up, it's a case of
passing -msoft-float down to gas in cases where gas accepts it.
(Would need to be a configure check, unfortunately.)

Richard