<div dir="ltr"><div dir="ltr">On Tue, 24 Nov 2020 at 20:16, Romero, Nichols A. via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_-3009334284301815401WordSection1">
<p class="MsoNormal"><span style="font-size:11pt">In support of ongoing efforts with the new Flang compiler that was recently added to LLVM Project, we plan to expand the LLVM Test Suite to include additional Fortran tests. This will require some infrastructure
 work, e.g., to specify a Fortran compiler and flags which will then enable the Fortran tests.</span></p></div></div></blockquote><div><br></div><div>Hi Nick,</div><div><br></div><div>This sounds like a no-brainer to me (ie. obviously good thing to have).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-3009334284301815401WordSection1"><p class="MsoNormal"><span style="font-size:11pt">We are focusing on tests in the following area:</span><br></p>
<p class="MsoNormal"><span style="font-size:11pt">- "smaller" language-centric tests,</span></p></div></div></blockquote><div><br></div><div>We already have some for C and C++, it would be nice to reuse the same infrastructure (or make it better while you're at it). It's a good proof of concept to the rest of the infrastructure that building Fortran programs works in the test-suite. I'd start here and only add those in the first patch.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-3009334284301815401WordSection1"><p class="MsoNormal"><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">- high-performance computing proxy-apps (particularly from Department of Energy projects), similar to the C/C++ proxy apps we already have,</span></p></div></div></blockquote><div><br></div><div>We had some trouble with the results of those programs in the past, when checking them (ie. diff) against the "golden standard". You should be able to change the driver program (the main function) to output some values or aggregations that don't change the precision of the calculations on different architectures and OSs, but still can detect differences if the numbers change too much. It's a fine tuning process that takes a while but makes for robust checks.</div><div><br></div><div>Some programs used to compute a hash of the output and compare that, but it was really hard to find out what's wrong by just looking at hashes. It also doesn't help with natural floating point variations between targets, so best to avoid those.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-3009334284301815401WordSection1"><p class="MsoNormal"><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">- OpenMP tests: multi-threaded and GPU offload (once the OpenMP/parallelism testing support was merged into the LLVM Test Suite, separate thread).</span></p></div></div></blockquote><div><br></div><div>Sounds great! Two birds. :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-3009334284301815401WordSection1"><p class="MsoNormal"><span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">As a first step we'll include the necessary CMake glue for the Fortran SPEC benchmarks, similar to CMake files we use to run the C/C++ ones.</span></p></div></div></blockquote><div><br></div><div>I imagined the first step to make it work on the test-suite itself, not on the SPEC link. I believe these are two different objectives. One is to make the test-suite validate Fortran code generation at a higher level than just the Lit tests and make sure the upstream code is on par by having public buildbots on it, while the other is to improve downstream testing on non-public benchmarks that will not have a direct effect on commits and general progress validation.</div><div><br></div><div>Both are important, but the upstream part is more important for the upstream community. I'd favour that to gain community support and do the SPEC part on the side.</div><div><br></div><div>cheers,</div><div>--renato <br></div></div></div>