From jules at codesourcery.com Fri Feb 1 20:32:21 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Fri, 01 Feb 2008 15:32:21 -0500 Subject: [patch] Fix SSE2 mag() Message-ID: <47A381D5.4080208@codesourcery.com> The mag mask had the wrong width for each element (24 bits instead of 32). This was causing coverage_unary to fail. Not sure why this wasn't showing up with buildbot. Perhaps the buildbot configs are not using --enable-simd-loop-fusion? Also, this wouldn't have shown up when IPP was enabled because IPP mag takes precendence of SIMD loop fusion. Patch applied to trunk and branches/1.4. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mag.diff URL: From stefan at codesourcery.com Fri Feb 1 20:39:25 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Fri, 01 Feb 2008 15:39:25 -0500 Subject: [vsipl++] [patch] Fix SSE2 mag() In-Reply-To: <47A381D5.4080208@codesourcery.com> References: <47A381D5.4080208@codesourcery.com> Message-ID: <47A3837D.30808@codesourcery.com> Jules Bergmann wrote: > Not sure why this wasn't showing up with buildbot. Perhaps the buildbot > configs are not using --enable-simd-loop-fusion? Also, this wouldn't > have shown up when IPP was enabled because IPP mag takes precendence of > SIMD loop fusion. That's strange indeed. As demonstrated here: https://intranet.codesourcery.com/buildbot/vsiplxx/builders/SerialBuiltin32/builds/8/steps/build_bdist/logs/stdio buildbot does use --enable-simd-loop-fusion, and no IPP is present in the 'Builtin' build variants. I'm not sure why the appropriate test didn't show the failure. -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From jules at codesourcery.com Fri Feb 1 20:54:58 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Fri, 01 Feb 2008 15:54:58 -0500 Subject: [vsipl++] [patch] Fix SSE2 mag() In-Reply-To: <47A3837D.30808@codesourcery.com> References: <47A381D5.4080208@codesourcery.com> <47A3837D.30808@codesourcery.com> Message-ID: <47A38722.50703@codesourcery.com> Stefan Seefeld wrote: > Jules Bergmann wrote: > >> Not sure why this wasn't showing up with buildbot. Perhaps the >> buildbot configs are not using --enable-simd-loop-fusion? Also, this >> wouldn't have shown up when IPP was enabled because IPP mag takes >> precendence of SIMD loop fusion. > > That's strange indeed. As demonstrated here: > > https://intranet.codesourcery.com/buildbot/vsiplxx/builders/SerialBuiltin32/builds/8/steps/build_bdist/logs/stdio > > > buildbot does use --enable-simd-loop-fusion, and no IPP is present in > the 'Builtin' build variants. I'm not sure why the appropriate test > didn't show the failure. Hmm, sure does. That's a 32-bit build (-m32). Does buildbot cover SerialBuiltin64? I wouldn't expect SSE2 to be disabled in 32-bit, but ... -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From jules at codesourcery.com Fri Feb 1 20:59:49 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Fri, 01 Feb 2008 15:59:49 -0500 Subject: [vsipl++] [patch] Fix SSE2 mag() In-Reply-To: <47A38722.50703@codesourcery.com> References: <47A381D5.4080208@codesourcery.com> <47A3837D.30808@codesourcery.com> <47A38722.50703@codesourcery.com> Message-ID: <47A38845.8030505@codesourcery.com> Jules Bergmann wrote: > Stefan Seefeld wrote: >> Jules Bergmann wrote: >> >>> Not sure why this wasn't showing up with buildbot. Perhaps the >>> buildbot configs are not using --enable-simd-loop-fusion? Also, this >>> wouldn't have shown up when IPP was enabled because IPP mag takes >>> precendence of SIMD loop fusion. >> >> That's strange indeed. As demonstrated here: >> >> https://intranet.codesourcery.com/buildbot/vsiplxx/builders/SerialBuiltin32/builds/8/steps/build_bdist/logs/stdio >> >> >> buildbot does use --enable-simd-loop-fusion, and no IPP is present in >> the 'Builtin' build variants. I'm not sure why the appropriate test >> didn't show the failure. > > Hmm, sure does. > > That's a 32-bit build (-m32). Does buildbot cover SerialBuiltin64? > > I wouldn't expect SSE2 to be disabled in 32-bit, but ... > Interesting. SerialBuiltin32-release (is that the same as SerialBuiltin32 builder?) shows the following for check_config.cpp: Sourcery VSIPL++ Library Configuration VSIP_IMPL_PAR_SERVICE - 0 (Serial) VSIP_IMPL_IPP - 0 VSIP_IMPL_SAL - 0 VSIP_IMPL_CBE_SDK - 0 VSIP_IMPL_HAVE_SIMD_LOOP_FUSION - 0 VSIP_IMPL_HAVE_SIMD_GENERIC - 0 VSIP_IMPL_PREFER_SPLIT_COMPLEX - 0 VSIP_IMPL_HAS_EXCEPTIONS - 0 VSIP_IMPL_ALLOC_ALIGNMENT - 32 __SSE__ - 0 __SSE2__ - 0 __VEC__ - 0 _MC_EXEC - 0 Sourcery VSIPL++ Compiler Configuration __GNUC__ - 3 VSIP_IMPL_HAVE_SIMD_LOOP_FUSION is 0. So is __SSE__ and __SSE2__. see https://intranet.codesourcery.com/buildbot/vsiplxx/report/SerialBuiltin32-release.html#check_config.cpp -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From jules at codesourcery.com Fri Feb 1 21:11:14 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Fri, 01 Feb 2008 16:11:14 -0500 Subject: [vsipl++] [patch] Fix SSE2 mag() In-Reply-To: <47A38845.8030505@codesourcery.com> References: <47A381D5.4080208@codesourcery.com> <47A3837D.30808@codesourcery.com> <47A38722.50703@codesourcery.com> <47A38845.8030505@codesourcery.com> Message-ID: <47A38AF2.20809@codesourcery.com> > SerialBuiltin32-release (is that the same as SerialBuiltin32 builder?) > shows the following for check_config.cpp: > VSIP_IMPL_HAVE_SIMD_LOOP_FUSION - 0 > VSIP_IMPL_HAVE_SIMD_GENERIC - 0 Ok, this is what I think what is going on. VSIP_IMPL_HAVE_SIMD_LOOP_FUSION is stored in the acconfig.hpp, regardless of --{enable,disable}-shared-acconfig. I recently changed config to always set simd loop fusion for both release and debug variants. However, before that change, debug variants typically did not have simd loop fusion. It is likely that the non-mondo config buildbot uses still had simd loop fusion turned off for the debug variant of SerialBuiltin32. If that got build after the release variant, its acconfig.hpp would take precedence. In the short term (for 1.4), enabling simd loop fusion for both debug and release variants sidesteps the problem. In the medium term (post 1.4), we should fix simd loop fusion to respect --{enable,disable}-shared-acconfig. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From jules at codesourcery.com Mon Feb 4 19:10:35 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Mon, 04 Feb 2008 14:10:35 -0500 Subject: [patch] Unhardcode EMBED_SPU m32/m64 Message-ID: <47A7632B.8050807@codesourcery.com> Un-hardcode the m32/m64 flag given to embed-spu. Patch applied. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: embed.diff URL: From jbateman at vmetro.com Mon Feb 11 20:28:44 2008 From: jbateman at vmetro.com (Jeff Bateman) Date: Mon, 11 Feb 2008 14:28:44 -0600 Subject: VSIPL++ availability for PowerPC AltiVec Message-ID: <724DC56D023CFE469ADB035983F15BFC0206EB90@PLATO2.vmetro.com> Hi, Please advise - is VSIPL++ available for AltiVec? Or, might it be ported to AltiVec in the (near) future? Thanks, Jeff Bateman, Senior Systems Engineer VMETRO Inc. 171 E. State Street, Suite 275, Box 120 Ithaca, NY 14850-5548 Voice (607)272-5494 ext. 22 Fax (607)272-5498 jbateman at vmetro.com http://www.vmetro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From brooks at codesourcery.com Mon Feb 11 21:10:00 2008 From: brooks at codesourcery.com (Brooks Moses) Date: Mon, 11 Feb 2008 13:10:00 -0800 Subject: [vsipl++] VSIPL++ availability for PowerPC AltiVec In-Reply-To: <724DC56D023CFE469ADB035983F15BFC0206EB90@PLATO2.vmetro.com> References: <724DC56D023CFE469ADB035983F15BFC0206EB90@PLATO2.vmetro.com> Message-ID: <47B0B9A8.4000206@codesourcery.com> Hello, Jeff, Jeff Bateman wrote, at 2/11/2008 12:28 PM: > Please advise - is VSIPL++ available for AltiVec? Or, might it be ported > to AltiVec in the (near) future? Yes, Altivec is supported, and we will be producing a PowerPC-Altivec binary package as part of the upcoming 1.4 release. VSIPL++ contains some internal SIMD code, and also depends heavily on the BLAS, LAPACK, and FFTW libraries that it is linked with for the back-end computation, so as long as you compile the VSIPL++ library and your code with the relevant compiler options and link with Altivec versions of those libraries, you should see the library making good use of the Altivec extensions. Fedora 7 provides Altivec-enabled versions of ALTAS as standard RPMS ("atlas-altivec" and "atlas-altivec-devel"); we've had success linking against those, using the following configure options: --with-lapack=atlas --with-atlas-include=/usr/include/atlas --with-atlas-libdir=/usr/lib/altivec (Note the libdir option in particular; Fedora also has a non-Altivec ATLAS that goes in /usr/lib, which would be used if you don't explicitly point to the /usr/lib/altivec ones.) Also, I believe that the standard Fedora FFTW3 packages ("fftw" and "fftw-devel") use Altivec as well. The configure flag to link against those is simply: --enable-fft=fftw3 Finally, for GCC you will want to include CXXFLAGS="-maltivec" in the configure line; other compilers will need an equivalent option unless they enable Altivec extensions by default. Hope that helps, and let us know if you have further questions! Thanks, - Brooks From jbateman at vmetro.com Mon Feb 11 21:32:50 2008 From: jbateman at vmetro.com (Jeff Bateman) Date: Mon, 11 Feb 2008 15:32:50 -0600 Subject: [vsipl++] VSIPL++ availability for PowerPC AltiVec References: <724DC56D023CFE469ADB035983F15BFC0206EB90@PLATO2.vmetro.com> <47B0B9A8.4000206@codesourcery.com> Message-ID: <724DC56D023CFE469ADB035983F15BFC0206EBB0@PLATO2.vmetro.com> Brooks, Your prompt response is much appreciated, and has been forwarded to appropriate VMETRO personnel for consideration. It's great news that AltiVec is being supported. One further question: is there any support yet under VxWorks 6.x? Jeff Bateman, Senior Systems Engineer VMETRO Inc. 171 E. State Street, Suite 275, Box 120 Ithaca, NY 14850-5548 Voice (607)272-5494 ext. 22 Fax (607)272-5498 jbateman at vmetro.com http://www.vmetro.com -----Original Message----- From: Brooks Moses [mailto:brooks at codesourcery.com] Sent: 11 February, 2008 16:10 To: Jeff Bateman Cc: vsipl++ at codesourcery.com Subject: Re: [vsipl++] VSIPL++ availability for PowerPC AltiVec Hello, Jeff, Jeff Bateman wrote, at 2/11/2008 12:28 PM: > Please advise - is VSIPL++ available for AltiVec? Or, might it be ported > to AltiVec in the (near) future? Yes, Altivec is supported, and we will be producing a PowerPC-Altivec binary package as part of the upcoming 1.4 release. VSIPL++ contains some internal SIMD code, and also depends heavily on the BLAS, LAPACK, and FFTW libraries that it is linked with for the back-end computation, so as long as you compile the VSIPL++ library and your code with the relevant compiler options and link with Altivec versions of those libraries, you should see the library making good use of the Altivec extensions. Fedora 7 provides Altivec-enabled versions of ALTAS as standard RPMS ("atlas-altivec" and "atlas-altivec-devel"); we've had success linking against those, using the following configure options: --with-lapack=atlas --with-atlas-include=/usr/include/atlas --with-atlas-libdir=/usr/lib/altivec (Note the libdir option in particular; Fedora also has a non-Altivec ATLAS that goes in /usr/lib, which would be used if you don't explicitly point to the /usr/lib/altivec ones.) Also, I believe that the standard Fedora FFTW3 packages ("fftw" and "fftw-devel") use Altivec as well. The configure flag to link against those is simply: --enable-fft=fftw3 Finally, for GCC you will want to include CXXFLAGS="-maltivec" in the configure line; other compilers will need an equivalent option unless they enable Altivec extensions by default. Hope that helps, and let us know if you have further questions! Thanks, - Brooks From jules at codesourcery.com Fri Feb 22 21:36:17 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Fri, 22 Feb 2008 16:36:17 -0500 Subject: [patch] Fixes for 1.4 Message-ID: <47BF4051.9030801@codesourcery.com> This patch fixes a set of related bugs in the 1.4 branch. The unaligned fixup code in the SIMD routines could process past the end of input if the input size was small enough (less than the SIMD width). This broke several tests fft2d, fft_block_type, and threshold, and perhaps some more. This adds a regression test for the case as well. This patch also brings the pwarp SIMD impl and test up-to-date with the AFRL branch. With these fixes, all tests should pass on Power, bar one that appears to be a compiler bug. AFAICT, the bug is triggered by some fancy test abstractions and not VSIPL++. I'm running tests now to verify, but plan to apply this soon and restart the 1.4 build. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fix-1.4.diff URL: From jules at codesourcery.com Tue Feb 26 17:31:34 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Tue, 26 Feb 2008 12:31:34 -0500 Subject: [patch] More 1.4 fixes Message-ID: <47C44CF6.7040507@codesourcery.com> Hopefully the last one! The new view_offset.cpp regression test (intended to cover the SIMD builtin functions) triggers a heisenbug in SIMD unaligned loop-fusion on Power with Fedora's GCC. This patch works around by allowing SIMD unaligned loop-fusion to be disabled in the Power binary packages. Patch applied. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fix-080226.diff URL: