[cairo] [PATCH] Fixes for ARM features runtime autodetection support

[Siarhei Siamashka]

On Wednesday 24 June 2009, Koen Kooi wrote:
> On 24-06-09 01:09, Siarhei Siamashka wrote:
> > NEON support is not enabled unless -mfloat-abi option is set. This
> > patch enables 'softfp' float-abi and requires EABI. Regarding
> > EABI floating point calling conventions, there is a choice between
> > 'soft', 'softfp' and 'hard'. Of these three, 'soft' and 'softfp'
> > are binary compatible. 'hard' is not yet supported by gcc, but it
> > should not introduce any problems as long as pixman NEON optimized
> > functions don't use floating point function arguments.
>
> There's a gcc 4.4.0 branch that supports 'hardfp' (finally!)

Are they going to add 'hardfp' in one of the official 4.4.x updates?
And does it really have this 'hardfp' name? I think I have seen it was
referred to as 'hard' in the discussions of preliminary gcc patches, but
surely may be wrong.

> and if you're in the to harry potter thing, CSL 2009q1 also supports it.

Thanks, maybe I will have a look at it.

> And I still think people should be passing their preferred float-abi using
> cflags and cairo should stay out of abi-munging.

In this case, -mfloat-abi=softfp is (almost) guaranteed not to cause any
problems. In the worst case (if future versions of gcc reject some combination
of flags), just NEON optimizations will not be enabled because the test code
snippet will fail to compile too.

But if pixman build scripts do not append -mfloat-abi=softfp for compiling the
source files with NEON functions, and people provide -mfloat-abi=soft option
globally via CFLAGS (to get a pixman binary which is also usable with the cpu
cores not having hardware floating point unit), NEON optimizations will fail
to get compiled in.

Another problem that I somehow overlooked before is the use of PLD instruction
in the pixman NEON code. it actually requires armv5te support, which has to be
enabled separately from NEON. So looks like having -mcpu is also needed. An
updated patch is attached.

> Maybe I'm tainted by working with mozilla code which hardcoded FPA
> behaviour and we had to wait 4 years for patches to land upstream since
> the mozilla people kept saying that there was no problem...

This sounds like a purely communication problem, not a technical one ;-)

Let's try to move the discussion to a more constructive side :-) I tried to
give an example, where the current pixman build system fails to provide
expacted result. Do you see any immediate problems where my proposed patch
would fail? Do you have any better solutions?

PS. I'm not sure how it is compatible with RVCT or other compilers. But
I guess that the first priority now is to get NEON optimizations rock solid
and fast at least with gcc.

-- 
Best regards,
Siarhei Siamashka
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Added-mfloat-abi-option-for-ARM-NEON-runtime-autode.patch
Type: text/x-diff
Size: 1552 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20090628/0dc669a3/attachment.patch