The DECLARE_ALIGNED_8 macro is defined to align to 16 bytes instead
the 8 suggested by the name on some CPUs. None of the uses of this
macro ever need 16-byte alignment, cases which once did having been
changed to always specify 16 bytes explicitly.
Originally committed as revision 19737 to svn://svn.ffmpeg.org/ffmpeg/trunk
1.3x and 3% on G4.
Though I think only part of this speedup is due to my optimizations per se;
some of it is that I got a better roll on the GCC random code generator.
Trivial reorderings of this function have a disproportionate effect on speed.
Originally committed as revision 19726 to svn://svn.ffmpeg.org/ffmpeg/trunk
The first member of struct ScanTable is a simple pointer, extra alignment
of which serves no purpose. The alignment specifier was added along with
some Altivec optimisations also adding a 16-byte-aligned array at the end
of struct ScanTable. Presumably the redundant, outer alignment was added
by mistake. The inner one is clearly sufficient.
Originally committed as revision 19724 to svn://svn.ffmpeg.org/ffmpeg/trunk
These arrays are passed to functions for which we promise 16-byte
alignment, so make sure we fulfil that promise.
Originally committed as revision 19716 to svn://svn.ffmpeg.org/ffmpeg/trunk
Bluray subtitle decoder instead of as small as possible.
This avoids completely unnecessary issues with e.g. libswscale.
(See r19673)
Patch by Stephen Backway, stev391 A exemail D com D au
Originally committed as revision 19714 to svn://svn.ffmpeg.org/ffmpeg/trunk
Storing a single element from a vector where all elements have the same
value does not require an aligned destination. Which element is stored
depends on the alignment of the destination address, but since they all
have the same value, the result is the same regardless of the alignment.
Originally committed as revision 19696 to svn://svn.ffmpeg.org/ffmpeg/trunk
Instead of filling a local array with the desired value and loading it,
load a single element and vec_splat() it to fill the vector.
Originally committed as revision 19691 to svn://svn.ffmpeg.org/ffmpeg/trunk
decoders instead of as small as possible.
This avoids completely unnecessary issues with e.g. libswscale.
Originally committed as revision 19673 to svn://svn.ffmpeg.org/ffmpeg/trunk
There is a theoretical possibility to pass a very long string to ff_parse,
which could crash if allocated from the stack. This allows the allocation
to be checked properly.
Originally committed as revision 19670 to svn://svn.ffmpeg.org/ffmpeg/trunk
pred_order can never exceed 32, so always allocating that amount is safe
and not very wasteful.
Originally committed as revision 19669 to svn://svn.ffmpeg.org/ffmpeg/trunk