<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 24, 2015 at 7:29 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">----- Original Message -----<br>
> From: "Mark Abraham" <<a href="mailto:mark.j.abraham@gmail.com">mark.j.abraham@gmail.com</a>><br>
> To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>><br>
> Cc: <a href="mailto:llvm-bgq-discuss@lists.alcf.anl.gov">llvm-bgq-discuss@lists.alcf.anl.gov</a><br>
</span><span class="">> Sent: Tuesday, March 24, 2015 12:35:20 PM<br>
> Subject: Re: [Llvm-bgq-discuss] New bgclang nighty builds (and other updates)<br>
><br>
><br>
</span><span class="">> Hi Hal,<br>
><br>
><br>
> Thanks very much for the update & effort.<br>
><br>
<br>
</span>You're very welcome.<br>
<span class=""><br>
><br>
> I tried out the default bgclang 3.6.0 on vesta, but found a bunch of<br>
> the GROMACS SIMD-layer unit tests failing. These need correct QPX<br>
> vector intrinsics available. From memory, things worked fine with<br>
> bgclang in ~August last year, but I no longer have those results. Is<br>
> there a simple way I can compile on vesta with older bgclang to see<br>
> where a problem might lie? Otherwise / depending what I learn, I'll<br>
> break out a debugger.<br>
<br>
</span>The old builds are still all installed. Just use the MPI wrappers from:<br>
<br>
/home/projects/llvm/<whatever>/mpi/bgclang/bin -- I don't know exactly which build you were using in August of last year, r209570-20140527 maybe?<br></blockquote><div><br></div><div>Yes, that was it, looking at some cruft in my former build script. In any case, the latest GROMACS SIMD single-precision unit tests pass on that old compiler version (3.5.0), and many of them fail in a release build on the default 3.6.0 bgclang on vesta. For some of the cases, it looks like some junk memory gets loaded, somehow. A few tests pass, but no theme for passing or failing tests leaps out at me. Double precision unit tests are OK, though.</div><div><br></div><div>Naturally, in debug mode most of the tests pass. However, the two I looked at in ddt were fine up until they called vec_extract(x, 0) e.g. on lines <a href="https://github.com/gromacs/gromacs/blob/master/src/gromacs/simd/impl_ibm_qpx/impl_ibm_qpx.h#L315">https://github.com/gromacs/gromacs/blob/master/src/gromacs/simd/impl_ibm_qpx/impl_ibm_qpx.h#L315</a> (where  a SIMD vector of 1 2 3 1 was summed to 3, rather than 7) and <a href="https://github.com/gromacs/gromacs/blob/master/src/gromacs/simd/impl_ibm_qpx/impl_ibm_qpx.h#L462">https://github.com/gromacs/gromacs/blob/master/src/gromacs/simd/impl_ibm_qpx/impl_ibm_qpx.h#L462</a> (where a SIMD vector dot product of the first 3 lanes returns a garbage answer). So maybe that is a productive lead?</div><div><br></div><div>I couldn't inspect the disassembly in ddt, so I'm not sure where we can take this from here, Hal. Tarball of test results attached.</div><div><br></div><div>Thanks,</div><div><br></div><div>Mark</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888"><br>
 -Hal<br>
</font></span><div class=""><div class="h5"><br>
><br>
><br>
> Thanks,<br>
><br>
><br>
> Mark<br>
><br>
><br>
><br>
><br>
> On Fri, Mar 20, 2015 at 12:15 AM, Hal Finkel < <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> ><br>
> wrote:<br>
><br>
><br>
> Hello everyone,<br>
><br>
> First, let me apologize to everyone, this is a few months late...<br>
> but, hopefully, this will never be a problem again...<br>
><br>
> I now have a system setup which automatically pulls in upstream<br>
> changes and tries to merge those with the bgclang-specific patches,<br>
> and then builds the resulting suite of bgclang RPMs. When this<br>
> succeeds, the RPMs should be posted automatically to:<br>
><br>
> <a href="http://www.mcs.anl.gov/~hfinkel/bgclang/" target="_blank">http://www.mcs.anl.gov/~hfinkel/bgclang/</a><br>
> (note that installing a build from here now also requires both the<br>
> 'stage1' and 'stage2' RPMs as well)<br>
><br>
> The first such nightly build, r232720-20150319, has been posted to<br>
> that page.<br>
><br>
> And, for the curious, the local repositories used for version control<br>
> are now mirrored to github:<br>
><br>
> <a href="https://github.com/hfinkel/clang-bgq" target="_blank">https://github.com/hfinkel/clang-bgq</a><br>
> <a href="https://github.com/hfinkel/llvm-bgq" target="_blank">https://github.com/hfinkel/llvm-bgq</a><br>
> <a href="https://github.com/hfinkel/bgclang-aux" target="_blank">https://github.com/hfinkel/bgclang-aux</a><br>
> <a href="https://github.com/hfinkel/compiler-rt-bgq" target="_blank">https://github.com/hfinkel/compiler-rt-bgq</a><br>
> <a href="https://github.com/hfinkel/libcxx-bgq" target="_blank">https://github.com/hfinkel/libcxx-bgq</a><br>
> <a href="https://github.com/hfinkel/openmp-bgq" target="_blank">https://github.com/hfinkel/openmp-bgq</a><br>
> <a href="https://github.com/hfinkel/sleef-bgq" target="_blank">https://github.com/hfinkel/sleef-bgq</a><br>
><br>
> Compared to the latest "released" version (r220548-20141024), the<br>
> most-recent nightly build does show some performance regressions,<br>
> and there are a few things I've not even tested yet (LTO, ASan,<br>
> etc.), but it also contains a number of bug fixes and improvements,<br>
> so feel free to test on your applications.<br>
><br>
> One particular noteworthy improvement is that our OpenMP runtime<br>
> library now has affinity support enabled. This means that all of the<br>
> OpenMP 4 affinity features should work, and also that the default<br>
> thread<->core bindings are now sensible.<br>
><br>
> The bgclang wrapper script no longer disables 'fast-isel' instruction<br>
> selection at -O0, so your debug builds should now be faster too.<br>
> Also, the automated vectorization of math functions using our SLEEF<br>
> library adaptation is controlled using the new -fveclib flag (so the<br>
> wrapper script contains -fveclib=SLEEF, and you can add<br>
> -fveclib=none to turn it off if desired for whatever reason).<br>
><br>
> Also, the core QPX support has been contributed upstream (although<br>
> not yet the Clang-level intrinsics support); so if you're using LLVM<br>
> as a library, and want to just build from upstream sources instead<br>
> of depending on the bgclang builds, that is now possible.<br>
><br>
> Thanks again everyone, and please let me know if you experience any<br>
> difficulties,<br>
> Hal<br>
><br>
> --<br>
> Hal Finkel<br>
> Assistant Computational Scientist<br>
> Leadership Computing Facility<br>
> Argonne National Laboratory<br>
> _______________________________________________<br>
> llvm-bgq-discuss mailing list<br>
> <a href="mailto:llvm-bgq-discuss@lists.alcf.anl.gov">llvm-bgq-discuss@lists.alcf.anl.gov</a><br>
> <a href="https://lists.alcf.anl.gov/mailman/listinfo/llvm-bgq-discuss" target="_blank">https://lists.alcf.anl.gov/mailman/listinfo/llvm-bgq-discuss</a><br>
><br>
><br>
<br>
--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</div></div></blockquote></div><br></div></div>