[cairo] [cairo-announce] [ANNOUNCE] Stable pixman release 0.16.0 now available

[Jonathan Morton]

> Pixman puts -mcpu only into the flags for compiling some selected files...

> So pixman adds too little to be usefull and what it adds is 
> not right for the target I'm targetting. Can we please add a 
> --I'm-using-ARM-but-actually-know-what-I'm-doing configure switch to 
> disable this behaviour?

What Pixman tries to do is build in the optimised backends for recent
versions of the ARM architecture, just in case the code is run on a
newer chip than it was compiled for.  Unlike the x86 world, where a
motherboard swap is a normal upgrade method and doesn't usually require
a kernel change, I'm not sure how much this makes sense.

The real problem is that the GNU assembler for ARM (which of course is
part of the GCC backend) rejects instructions that don't match the ARM
architecture it's been configured for.  The GNU folks probably consider
this a feature, but it means that we can't inject NEON instructions on a
runtime-configured code path without some compile-time gymnastics.

Compounding this is that GCC rejects -march and -mcpu combinations, so
if the user uses one or the other to explicitly describe their machine,
we can't override it with the opposing form.  A possible solution would
be to try both forms (in combination with the user's flags) and see
which one works.

The proliferation of ABIs on ARM only worsens the situation, especially
since there are an amazing number of ARM chips without FPUs (or even FP
registers) which affects the default ABI choice.  NEON, of course, uses
the FP registers, a bit like MMX does.  Leaving out the ABI flag would
simply disable NEON on FPU-less builds, which might be the right
solution too.

-- 
------
From: Jonathan Morton
      jonathan.morton at movial.com