[FFmpeg-devel] [PATCH] vp9: change order of operations in adapt_prob().

[Ronald S. Bultje]

Hi Michael,

On Fri, Oct 14, 2016 at 2:31 PM, Michael Niedermayer <michael at niedermayer.cc
> wrote:

> On Fri, Oct 14, 2016 at 08:29:37PM +0200, Michael Niedermayer wrote:
> > On Fri, Oct 14, 2016 at 11:09:30AM -0700, James Zern wrote:
> > > Ronald,
> > >
> > > On Fri, Oct 14, 2016 at 10:01 AM, Ronald S. Bultje <rsbultje at gmail.com>
> wrote:
> > > > This is intended to workaround bug "665 Integer Divide Instruction
> May
> > > > Cause Unpredictable Behavior" on some early AMD CPUs, which causes a
> > > > div-by-zero in this codepath, such as reported in Mozilla bug
> #1293996.
> > > >
> > > > Note that this isn't guaranteed to fix the bug, since a compiler is
> free
> > > > to reorder instructions that don't depend on each other. However, it
> > > > appears to fix the bug in Firefox, and a similar patch was applied to
> > > > libvpx also (see Chrome bug #599899).
> > > >
> > >
> > > I recently made a few additional changes as this regressed in chrome
> > > [1][2], but just like this change there's no guarantee it won't occur
> > > again.
> >
> > maybe you can use empty "asm volatile(:::"memory")" statments to
> > prevent unwanted instruction reordering by the compiler
> > never tried something like this so dunno, also it would be specific
> > to gcc compatible compilers but should not be architecture specific
>
> thinking again, why dont you write the function in asm for x86 ?
> this would take the compiler out of the equation


I think the primary reason is that "this seems to work". Don't forget that
the bug is in the hardware, not in the code, so I don't want to make the
code needlessly (well... maybe that's debatable) complicated for a problem
that isn't really ours...

But I guess I'm open to hearing everyone else's opinion on this - if people
want me to make the workaround more persistent I can work on that.

Ronald