Hi folks. Mozilla had some issues with the MMX optimized frag_recon functions over the last days, and I was able to track the problem down. The code itself is fine, but it unfortunately it has the tendency to cause a non-deterministic compiler bug. The whole discussion is here: https://bugzilla.mozilla.org/show_bug.cgi?id=474937 After thinking about the problem I've suggested to remove all optimized frag_recon assembler functions and replace them with MMX intrinsic based versions. My hope is that the problem will dissapear that way because the new functions will be no special cases for the compiler anymore. If we only fix/remove the function that caused the problems (that's the current bug-fix) we don't win much because the problem may occur a week or two later at another place. Any comments? - Nils
It seems a reasonable solution for the VC compiler, but seeing as this code is very unlikely to change in the future it seems a shame to force a performance hit on the GCC version because of a Microsoft bug. --John theora-dev-request at xiph.org wrote:> Date: Tue, 03 Feb 2009 06:38:42 +0100 > From: Nils Pipenbrinck <n.pipenbrinck at cubic.org> > Subject: [theora-dev] Issues with Win32 MMX code > To: theora-dev at xiph.org > Message-ID: <4987D862.4070706 at cubic.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi folks. > > Mozilla had some issues with the MMX optimized frag_recon functions over > the last days, and I was able to track the problem down. The code itself > is fine, but it unfortunately it has the tendency to cause a > non-deterministic compiler bug. > > The whole discussion is here: > > https://bugzilla.mozilla.org/show_bug.cgi?id=474937 > > > After thinking about the problem I've suggested to remove all optimized > frag_recon assembler functions and replace them with MMX intrinsic based > versions. My hope is that the problem will dissapear that way because > the new functions will be no special cases for the compiler anymore. > > If we only fix/remove the function that caused the problems (that's the > current bug-fix) we don't win much because the problem may occur a week > or two later at another place. > > Any comments? > > - Nils > >
On Tue, Feb 3, 2009 at 1:07 PM, John Ridges <jridges at masque.com> wrote:> It seems a reasonable solution for the VC compiler, but seeing as this > code is very > unlikely to change in the future it seems a shame to force a performance > hit on the > GCC version because of a Microsoft bug.The MSVC assembly has always been separate, because the two compilers have incompatible inline assembly syntax. As I understand the proposal, only the dec/x86_vc files would be converted to intrinsics. This is expected to generate slower code, but avoid the MSVC code generation bug. GCC output would be unchanged. -r
On Mon, Feb 2, 2009 at 9:38 PM, Nils Pipenbrinck <n.pipenbrinck at cubic.org> wrote:> After thinking about the problem I've suggested to remove all optimized > frag_recon assembler functions and replace them with MMX intrinsic based > versions. My hope is that the problem will dissapear that way because > the new functions will be no special cases for the compiler anymore.Hard to say. In theory the intrinsics might compile on gcc too someday, which would be great. But you say in the bugzilla thread that you expect the intrinsics version to be slower. Benchmarks are in order, I think. If the problem is with the inline assembly, what about assembling the files separately? Rather than add a build dependency, I think including the object files in svn (or just releases) would be reasonable here, since they're touched rarely. I don't know much about this. Can you avoid the problem by running the current asm through nasm (or masm for that matter) and adding the output to the msvc build? -r