[opus] [RFC PATCHv1] armv7: celt_pitch_xcorr: Introduce ARM neon intrinsics

[Timothy B. Terriberry]

Viswanath Puttagunta wrote:
> Sorry, I don't know what .pc file is. Also no strong opinions on my

A pkg-config file (e.g., opus.pc.in)

> side.. but I was merely following
> guidance from
> http://www.gnu.org/software/automake/manual/html_node/Per_002dObject-Flags.html
> which specifically advocates against per object flags.

Well, I don't claim to know anything about automake, but they seem to be 
supported just fine. We're already doing things this way, and I'd like 
to keep things consistent.

> I really don't even understand how the FIXED point code is even
> working.. doesn't it face this
> same problem? Don't you get compile error that function signatures are
> not matching?

You're right. This got broken by the SSE intrinsics, but it only 
generates a warning, not an error (and by accident, the code actually 
works). But yeah, that's a mess. I submitted 
<https://review.xiph.org/540/> to fix it (waiting on review to land).

> thought is that I'm really not
> sure why arch is being passed for each call to celt_pitch_xcorr() and
> we do a table lookup for
> the appropriate function every time.

The theory here is that a lookup in a global table is not any slower in 
practice than a virtual function call, but we have the advantage that we 
can put the table in a read-only data segment and mask off the table 
lookup index to guarantee that we never read outside the table, even if 
the codec state becomes completely corrupted (e.g., by a security 
exploit). If we stored explicit function pointers somewhere writable, 
such corruption could be used to redirect control flow arbitrarily. It's 
just reducing attack surface (belt-and-suspenders).

> amount of time... could you please suggest an alternative here?.. Because I'm
> really out of ideas in this area and could use some advise / direction.

Sorry, this is okay for now since I can't think of a good alternative to 
suggest (if I could have I would have). Was just throwing that out there 
in case you had a good idea.

> For aarch64,
> case $host_cpu in
>        aarch64*)
> the configure.ac code should be much smaller as we can make valid

Okay, if that's the plan of record then I withdraw my objection.