sure, i can expand/explain where i'm coming from. I wrote a lot of that 
neon code -- basically all the pieces using intrinsics. i'm a big fan of 
the intrinsics -- let the compiler manage all the register assignments, 
scheduling instructions and such. and I think that they are easier to 
maintain than hand assembly.
your comments indicate that you're getting 70% improvement (i take this 
as "almost 2x the speed"). that's pretty good considering that the 
first neon version was alread 3x faster than the scalar version. That 
extra bit would have me thinking about whether to bend my natural 
inclination to stay with the intrinsics.
as to what I was thinking to try ...
i was thinking perhaps to expand the int8x8's that i'd been using into 
int8x16's [with appropriate fattening of the other
intermediate types i'd used]. but as I re-read my code, i see that i 
widen my int8x8's to int16x8 -- so i'd need to widen an int8x16 to 
int16x16 and we don't have that data type.
It appears that the place I was having the ugly register spills was 
where I'd wanted to use intrinsics to generate some vld4.8 instructions 
in the S32A_D565_Opaque_Dither_neon routine. so my memory is doubly bad 
this evening. You can see there how I worked around the limitations in 
gcc to get clean vld4.8 generated code; the register allocation worked 
nicely and I wasn't seeing any strange register motion.
I might play the same trick that I used for the vld4.8's to get a 
"vld1.32 {d0,d1,d2,d3}" so that we get the big "wider loads are better" 
advantage; i'd have to code it to see whether it would hold together 
through the actual operations once it's in registers.
And your assembly code does do better with loading for the next round 
while finishing this round; i never mastered that with the intrinsics. I 
wouldn't be surprised if it reduces to that.
make sure to build & run skia_test -- the last go round of changes that 
I did for neon with Mike involved changes to track some updated 
semantics of SkAlpha255To256(). this took a little bit to get right -- 
and I think that the semantics of that routine might have changed back. 
skia_test was good for ferreting out that this wasn't right. you'll want 
to check external/skia/tests/Android.mk to make sure skia_test is being 
built for you.
and to be clear -- I haven't seen anything wrong in the code you posted 
(haven't worked through it either); it was more of a "have we exhausted 
what we could do with intrinsics" comment.
-- Ray Essick
According to XinQi@codeaurora.org on 06/16/10 19:36:
> Could you expand what you mean? Use inline assembly to implement it or
> to use intrinsic?
>
> On 2010年06月16日 22:28:52, ray.essick wrote:
>> I'd have written the version in opts/SkBlitRow_opts_arm.cpp run with
> even wider
>> operations if gcc had generated nicer code. The gcc 4.3.2 compiler I'd
> been
>> using did a lot of extra register spills when I last tried to get
> really wide --
>> perhaps the gcc 4.4.x stuff fixes that; it might be worth checking.
>
>
>
> http://codereview.appspot.com/1148042/show