[FFmpeg-devel] [PATCH] strict-aliasing-safe aes.c
Tue Jun 29 17:31:48 CEST 2010
On Tue, Jun 29, 2010 at 06:58:37AM +0200, Reimar D?ffinger wrote:
> On Mon, Jun 28, 2010 at 10:13:31PM +0200, Reimar D?ffinger wrote:
> > On Mon, Jun 28, 2010 at 10:02:15PM +0200, Michael Niedermayer wrote:
> > > On Mon, Jun 28, 2010 at 05:55:30PM +0200, Reimar D?ffinger wrote:
> > > > Hello,
> > > > this uses AV_WN32A, AV_WN64A etc. macros.
> > > > The generated code is the same on x86_64 (assuming I did not mess up that test).
> > >
> > > > aes.c | 20 +++++++++++++-------
> > > > 1 file changed, 13 insertions(+), 7 deletions(-)
> > > > 76705b63949d4abbe51b0d7d59537045ae91179a aesalias.diff
> > >
> > > this makes the code unreadable, iam thus against it.
> > Well, what is the alternative? The current code seems to not work with some compilers.
> Before you flame too much, I think I have an idea.
> I'm sure someone won't like it, but for now while it's
> only in my head I do like it.
> It should also solve the undocumented alignment requirement issue.
> I'll try to send a patch this evening.
Here is the patch.
Yes, it makes the code larger, but it seems ok to me personally.
It also removes almost all of the warnings.
IMO the API/ABI remains unchanged (well, except a few warnings,
and I admit it might break compilation for C++ users...).
It actually makes aes-test work again with my gcc 4.4.4.
Unfortunately, the generated asm code changes for clang, but
make aes-test fails with
> aes-test.o: file not recognized: File format not recognized
And the code for gcc before is incorrect, so I have no way to
benchmark right now...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7427 bytes
Desc: not available
More information about the ffmpeg-devel