Re: Preliminary MIPS N32 port now available

[Andreas Enge]

On Fri, Oct 18, 2013 at 11:41:24AM -0400, Mark H Weaver wrote:
> More importantly, because there are so many patches for Loongson 2F that
> are not yet ready to be applied upstream -- either because they are not
> sufficiently clean, or because they choose a compile-time configuration
> that uses Loongson-specific features or works around Loongson 2F bugs --
> I expect that we'll want to maintain a separate "loongson" branch for
> the foreseeable future, even if some of the patches are applied to
> core-updates.

Personally, I think mips64el should be a fully qualified release architecture
just as i686 and x86_64. So it would be better to have it in master and
not in a separate branch.

So far, the only machines of this architecture available (and of interest)
to developers are loongson. So I would argue that for the time being,
mips64el=loongson, and all patches necessary for loongson should be applied
to master (assuming they do not interfere with i686 and x86_64, which I would
not expect for decent patches that could be sent upstream). Maybe we might
wish to keep a "loongson" in the name of the patches to make them easily
identifiable.

> For example, 'pixman', used by both the X server and Cairo for low-level
> rendering operations, optionally includes code to use Loongson-specific
> SIMD vector instructions, but the choice of whether to use this code
> must be made at compile time.  The Loongson-specific code makes a
> dramatic improvement in rendering performance, but won't work at all on
> other MIPS processors.

Under the assumption mips64el=loongson, this would then not be a problem,
and we would use the compiler flags needed to enable loongson optimisations
on the mips64el architecture.

If potentially in the future someone comes up who can contribute to a
non-loongson mips64el port and has a corresponding machine, then we can
revise our policy, maybe by creating a new branch, maybe by considering
more fine-grained architectures (using the vendor field of the quadruple?).

Andreas