[cairo] [pixman] armv6+ & unaligned memory accesses

Siarhei Siamashka siarhei.siamashka at gmail.com
Sat Feb 13 14:51:14 PST 2010



> Subject: Check alignment of 'src' pointer in optimized ARM routines
> fbCompositeSrcAdd_8000x8000arm() tries to align 'dst' already but must
> check 'src' too.  Otherwise, the next 4-byte copy loop might access an odd
> 'src' address causing an alignment trap.

A bit more explanations about this issue would be nice to have. Linux has no
problems with unaligned word memory accesses on armv6 compatible processors
and anything newer. Was the alignment trap caught in some other OS?

> Patch from Enrico Scholz
> ---
> diff --git a/pixman/pixman-arm-simd.c b/pixman/pixman-arm-simd.c
> index 8aa81d2..f595325 100644
> --- a/pixman/pixman-arm-simd.c
> +++ b/pixman/pixman-arm-simd.c
> @@ -60,7 +60,7 @@ fbCompositeSrcAdd_8000x8000arm (pixman_op_t op,
>  	srcLine += srcStride;
>  	w = width;
> -	while (w && (unsigned long)dst & 3)
> +	while (w && (((unsigned long)dst & 3) || ((unsigned long)src & 3)))

This function may be also called when ((dst - src) & 3) is nonzero. In
this case, the processing would be run in this inefficient loop wasting
cycles on doing redundant checks for each iteration. The followup commit
explains this issue, but does nothing to fix it:

>  	{
>  	    s = *src;
>  	    d = *dst;
> --

I wonder if it makes sense to have separate variants of these optimizations?
One for the processors/operating systems which do support unaligned memory
accesses and can run at full speed (linux), and another one for those which
do not (some other systems?).

Best regards,
Siarhei Siamashka

More information about the cairo mailing list