[opus] [RFC PATCHv1] armv7: celt_pitch_xcorr: Introduce ARM neon intrinsics
Timothy B. Terriberry
tterribe at xiph.org
Mon Dec 1 12:19:01 PST 2014
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
> 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
> 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.
More information about the opus