[FFmpeg-devel] [PATCH] lavu/frame: Optimize frame_copy_video

[Jean Delvare]

Hi Derek,

On Tue, 15 Dec 2015 17:39:23 +0000, Derek Buitenhuis wrote:
> On 12/15/2015 5:23 PM, Jean Delvare wrote:
> > Looks like something different from what we were discussing here.
> 
> In which way?
> 
> That patch fixes pointer aliasing in the same way yours breaks it, AFAICT?

I see two completely different things.

The change I proposed is specific to one function, only changes const
vs non-const, and the object under discussion is being accessed for
reading only (thus the const pointer.) It would remove a memcpy but
does not introduce a direct copy (with =.)

The change you pointed us to is touching very generic functions,
handling by nature a very wide variety of pointer types for both
reading and writing.

So just because the change you pointed us to may be good and desirable,
doesn't imply that the change I am proposing is bad and undesirable.

Side note #1: if gcc really considers pointer types that only differ by
"const" as different when it comes to code optimization, it is
seriously broken IMHO. Unfortunately the man page is quite vague on the
topic ("unless the types are almost the same", can you be more vague
please.)

Side note #2: if strict-aliasing optimizations can do so much damage
to your code that you end up doing
  memcpy(arg, &(void *){ NULL }, sizeof(val));
to set a pointer to NULL, maybe you should consider building with
-fno-strict-aliasing.

Side note #3: I'm surprised this change was needed in the first place
as my understanding was that gcc would skip all strict-aliasing
optimizations for void pointers, which is what the affected functions
are handling. It's sad that the commit message is as vague as gcc's
manual page on the topic.

-- 
Jean Delvare
SUSE L3 Support