[FFmpeg-devel] [PATCH] strict-aliasing-safe aes.c

[Michael Niedermayer]

On Tue, Jun 29, 2010 at 02:02:41AM +0100, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > 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.
> >
> > Fix the compiler.
> 
> There is nothing wrong with the compiler.  It implements the C99
> language exactly as specified.

The C99 standard isnt everything, a mpeg2 encoder also could return
nothing but a black picture independant of the input, yet it wouldnt be a
reasonable mpeg encoder or a usefull one.
I know you are the one who prefered the mpeg demuxer to comply to the spec
even at the cost of not demuxing actual existing files.


> 
> > This language lawyering and pedantic gnu style compliance crussade is
> 
> This has nothing to do with GNU and everything to do with the C99 standard.

yes, that comment was about something else


> 
> > really annoying. Anything that gnu considers to be worth warning about makes
> > people run and change their code, and often to the worse.
> 
> In this particular case the code is in violation of the spec.  That
> the compiler only recently got the ability to detect this does not
> make it less of a violation.

again the comment is not about aliassing violations but warnings in general
if a new gcc version displays new warnings people will jump on changing code
even if the change goes to th worse and theres nothing wrong with the code
but just gcc not getting that something is used or a () just not making sense
there.


[...]

> 
> > I guess you would also replace the c code by a base64 encoded string of a
> > gif file if part of the c spec required it.
> 
> If that's what the spec required, of course.  

so i guessed correctly


> Now please send your
> straw man back wherever it came from.

ok


> 
> > what i think should be done is:
> > people should post a feature request on the <put affected compiler here> bug
> > tracker about it acting a bit more reasonable and handle such trivial
> > aliassing cases. And everyone who considers this important should reply
> > there and express his oppinon.
> 
> THERE IS NO BUG IN THE COMPILER!

please send your strawman back as well, i never said theres a bug.
I said the compiler behaves unreasonable and i clearly was talking about
a feature request.


> 
> > With a critical mass of compilers supporting this chances are probably good
> > to also get it into the C standard one day. And that would lead to more
> > readable and simpler code.
> 
> Strict aliasing IS A GOOD THING.  You yourself often complain about
> gcc not optimising fully in some cases where potential aliasing
> prevents it.  The recent discussion about src/dst in dct functions is
> a good example.  Stronger aliasing constraints would allow the split
> src/dst to be optimised just as much as the inplace version.

we arent talking about the same thing it seems.
I guess we agree that the compiler should generate fast code.
I guess we agree that fast code needs types sometimes accessed through
  different types.
I guess we agree that there must be some way for the programmer to specify
  how pointers can alias and some default rules about aliasing in absence.
What iam saying is that a compiler should detect 
*(uint32_t*)p
and accept it as correct code like it per spec has to accept
((magic_union_type*)p)->u32

I also think that the aliassing model used by gcc is severly lacking.
It for example lacks the possibility of the programmer specifying how
2 pointers can alias exactly. The issue just came up with the dct
optimization and forced us to adapt our design of it.
I dont like having to design our code around shortcommings of the compiler


> 
> > I dont mind us working around it here if theres some effort toward fixing
> > this where the problem is (aka compilers and the C spec) even if that effort
> > is small and unlikely to be successfull but if everything thats done is
> > directed toward turning every file into a unmaintaunable mess with not
> > one second spend on solving the actual problem then i dont think i
> > will approve such workarounds. Id like to have at least some hope even if
> > small that this red tape around every bit of optimized code one day would
> > become unneeded
> 
> The main author of libswscale is in no position to speak about an
> unmaintainable mess.

I have less problem maintaining it than you have with maintaining an average
politeness level free of personal insults

besides instead of continuing to reply to your language lawyering trolling
ill refer you to linus torvalds:
http://kerneltrap.org/mailarchive/linux-kernel/2007/10/26/359162
http://lkml.org/lkml/2003/2/26/158
Ive seen better quotes from him about it but i cant find them atm

try to troll him please


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100629/c4ba117d/attachment.pgp>