[FFmpeg-devel] [PATCH] ff_h[yc]scale_fast_mmext always clobbers %rbx

[Nick Lewycky]

On 6 May 2015 at 13:08, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:

> Nick Lewycky <nlewycky <at> google.com> writes:
>
> > On 6 May 2015 at 11:58, Carl Eugen Hoyos:
> >
> > > Nick Lewycky <nlewycky <at> google.com> writes:
> > >
> > > > This occurs when building ffmpeg with clang
> > > > -fsanitize=address -O1 -fPIE.
> > >
> > > What is the usecase for -O1?
> >
> > It's very important for asan. ASan instruments
> > every memory access (outside inline asm, for now)
> > and if we don't run the optimizer then every local
> > variable is a stack allocation with loads and
> > stores, and all those loads and stores get
> > instrumented leading to both crazy slowdown and
> > binary size increase.
>
> What I meant was (and I believe I wasn't clear):
> What is the usecase for -O1 as opposed to default
> optimization?
> Or in other words: Is the issue with clang also
> reproducible with -O2 and -O3?
>

Oh I see. Yes, it does.

I happened to use clang -O1 because that's our normal "unoptimized" ASan
configuration where I first found the bug. I assume it doesn't happen at
-O0 but I haven't checked, it does happen at higher optimization levels too.

> > Did you check performance with and without
> > > your patch?
> >
> > No.
>
> I believe such a performance test is a precondition
> for an asm patch (but I am not the maintainer).
>

I'm new here, I don't even know to test ffmpeg performance. I'm happy to
run something if you have a suggestion?

My two arguments are that correctness trumps performance (otherwise ffmpeg
could be "return 0" -- don't tempt me, I'm already a compiler optimization
engineer ;-) ), and that this is exactly what ffmpeg already did with PIC
disabled.