<div dir="ltr">Some perhaps relevant aspects that make testing users of LLVM like Halide challenging:<div><br></div><div>Halide uses the LLVM C++ APIs, but there isn't a good way to lock-step update it. So if we were to directly test Halide, it wouldn't link against the new LLVM.</div><div><br></div><div>Practically speaking though, the LLVM IR generated by Halide should continue to work with newer LLVM optimizations and code generation. So the idea would be to snapshot the IR in bitcode (which is at least reasonably stable) so that we could replay the tests as LLVM changes. We can freshen the bitcode by re-generating it periodically so it doesn't drift too far from what Halide actually uses.</div><div><br></div><div>The interesting questions IMO are:</div><div><br></div><div>1) Are folks happy using bitcode as the format here? I agree with Hal that it should be easy since Clang will actually Do The Right Thing if given a bitcode input.</div><div><br></div><div>2) Are folks happy with non-execution tests in some cases? I think Alina is looking at whether we can get a runtime library that will allow some of these to actually execute, but at least some of the tests are just snap-shots of a JIT, and would need the full Halide libraries (and introspection) to execute usefully.</div><div><br></div><div>-Chandler</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Feb 17, 2016 at 7:25 PM Hal Finkel via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000"><br><hr><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From: </b>"Alina Sbirlea via llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br><b>To: </b>"llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br><b>Sent: </b>Wednesday, February 17, 2016 7:25:17 PM<br><b>Subject: </b>[llvm-dev] RFC: Add bitcode tests to test-suite</blockquote></div></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000"><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><br><br><div dir="ltr">Hi all,<div><br></div><div>TL;DR: Add *.bc to test-suite; llc *.bc; run some.</div><div><br></div><div><div>We would like to propose adding bitcode tests to the llvm test-suite.</div></div><div><br></div><div>Recent LLVM bugs [2-4] prompted us to look into upstreaming a subset of the tests the Halide library [1] is running and we'd like the community's feedback on moving forward with this.<br></div><div><br></div><div>Halide uses LLVM and can generate bitcode, but we cannot add C++ tests to test-suite without including the library itself.</div><div>This proposal is also potentially useful for other cases where there is no C++ front-end.</div><div><br></div><div>As a first step we are interested in adding a set of correctness tests, for testing the IR without running the tests. Since these tests are generated, they are not instrumented like the .ll files in trunk, however we believe checking that llc runs without errors is still useful.</div><div>The bitcode files for Halide may also be large, so including them as regression tests is not an option. If the smaller tests are found to be valuable or covering cases no other tests cover, we can instrument them and move them into the llvm trunk further along, but that is not the goal of this proposal.</div><div>In addition, we're not sure whether the format for the tests should be .ll or .bc, we're open to either.</div><div><br></div><div>After this first step, we're interested in upstreaming bitcode tests and also running them.</div><div>We are very interested in tests for multiple architectures, aarch64 in particular, since this is where we have seen things break. This may motivate adding .ll files rather than .bc in order to include the "RUN:" target. </div><div>Where would these tests reside and with what directory structure? (similar to test/CodeGen?)</div><div><br></div><div>Suggestion on what's the best approach for extending the test-suite framework for this proposal are more than welcome.</div></div></blockquote></div></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000"><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"></blockquote>We already have architecture-specific tests in the test suite (e.g. SingleSource/UnitTests/Vector/{SSE,Altivec,etc.}, and Clang can deal with IR inputs. I suppose you need to compile some corresponding runtime library, but this does not seem like a big deal either. Mechanically, I don't see this as particularly complicated. I think the real question is: Is this the best way to have a kind of 'halide buildbot' that can inform the LLVM developer community?<br><br> -Hal</div></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000"><br><br><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><div></div><div><br></div><div>This is just the high-level overview to start off the discussion, I'm sure there are many more aspects to touch on. Looking forward to your feedback!</div><div><br></div><div><div>Thanks,</div><div>Alina</div><div><br></div><div><span style="font-size:12.8px">[1] </span><a href="http://halide-lang.org/" style="font-size:12.8px" target="_blank">http://<span>halide</span>-lang.org/</a></div><div>[2] Broken: r259800 => Fixed: r260131</div><div>[3] Broken: <span style="font-size:12.8px">r260569 => </span>Fixed: <span style="font-size:12.8px">r260701</span><br></div><div>[4] <a href="https://llvm.org/bugs/show_bug.cgi?id=26642" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=26642</a></div><div><br></div><div><br></div></div></div>
<br>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br></blockquote><br><br><br></div></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000">-- <br><div><span name="x"></span>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>