[FFmpeg-devel] lurking bugs in the mmx-related assembler code (?)

[wm4]

On Sun, 2 Oct 2016 02:25:30 +0200
Michael Niedermayer <michael at niedermayer.cc> wrote:

> On Sun, Oct 02, 2016 at 01:18:29AM +0200, Henrik Gramner wrote:
> > Ensuring that emms is issued before every single libc function call is
> > likely problematic.  
> 
> maybe, maybe not, iam not sure but
> calling emms between init/de/reinint and optimized inner loops should
> be doable, we generally shouldnt be doing malloc in highly optimized
> loops as factorizing allocation out and reusing buffers is likely
> a better choice

+1 for not leaving the C environment and the FPU in a broken state.

> beyond malloc() what else is there ?
> 
> string functions ?
> these are in fact not unlikely to use SIMD of some sort
> same for memcpy/move()
> 
> also there are callbacks like av_log() we should document any
> requirements that apply to them or ensure no such requirements exist
> 
> exact backtraces of where issues occur would be interesting to better
> understand how much code is affected by this
> 
> 
> > 
> > What if we simply document the requirement that C standard library
> > functions are assumed to not modify the x87 FPU state unless
> > specifically designated to handle floating-point numbers?  
> 
> thats like saying that we require undefined behavior to be defined
> in a specific way. We can do this but thats like saying we support
> only a subset of POSIX platforms and that subset could shrink at
> any time if implementations change
> 
> I think our first choice should be to comply to specs where its
> needed in practice and doable.
> when its not useful in practice and a total unreadable mess if done
> i would tend suggest to ignore specs. 
> 
> If all else fails we could add a emms call behind #if in
> av_malloc() and detect affected libcs but thats IMHO a ugly hack
> but better than declaring "non support"
> 

Yes, that would be a very ugly hack that should be avoided.