
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 3, 2018, at 11:44 AM, Daniel Sanders <<a href="mailto:daniel_l_sanders@apple.com" class="">daniel_l_sanders@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 2 Jul 2018, at 15:13, Matthias Braun via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I had similar gripes with unit testing machine function stuff. I personally would have preferred to create more tests based on a tool like llc rather than pushing more on the unit test side. Anyway I tried to push <a href="https://reviews.llvm.org/D48850" class="">https://reviews.llvm.org/D48850</a> in order to extend llc to be more amenable in the situations we want to test, but it ultimately wasn't accepted.<div class=""><br class=""></div><div class="">- Matthias</div><div class=""><div class=""><div class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jul 2, 2018, at 2:35 PM, Aditya Nandakumar via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">When writing MachineFunction unit tests, I find it quite tedious to verify correctness in C++. I would like to use FileCheck in UnitTests because FileCheck is extremely convenient/robust to verify correctness. In order to do so, I moved most of FileCheck’s implementation into a header (Support/FileCheck.h) and updated FileCheck.cpp to use this.</div><div class=""><br class=""></div><div class="">I ran into this while writing some target agnostic Legalization code in GISel where it’s not possible or extremely inconvenient to use llc.</div></div></div></blockquote></div></div></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">To elaborate on this, the motivating issue as I understand it is that there's portions of GlobalISel that will be needed by targets in the future but aren't used by the current set of targets that support GlobalISel. For example, of the various actions (widenScalar, narrowScalar, Lower, etc.) that can be taken on CTLZ, most of the current GlobalISel targets declare CTLZ legal for almost all the types they encounter in practice. Instead of leaving the other paths untested or unimplemented, you wanted to be able to test those parts of GlobalISel even though we lack a target that would allow us to test it with llc.</div></div></div></div></blockquote>Yup. That was the main issue. There are also cases where expansion of one instruction changes if some other opcode is legal/custom etc and there’s no way to test both paths/expansions for one target.<br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class="">Is that right?</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">What do others think of this? I would think there might be non GISel uses for FileCheck in unit tests, but I’m not sure.</div></div></div></blockquote></div></div></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I like the idea of being able to build a mock target to test the areas of GlobalISel that would normally only get very light testing. Being able to test the individual expansions in the combiner is going to be particularly useful as there’s several reasons an individual combine could bitrot over time such there being other combines that overlap many of the same cases, or just simply being a rare case.</div></div></div></div></blockquote>Yup. I think it would make testing combines/transformations much easier.<br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div>I'm not keen on moving the implementation to a header though. If we’re going to make it usable from unittests then I think we should turn it into a library and compile the implementation once.<br class=""></div></div></div></blockquote>I can definitely do that - this was a quick POC.</div><div>Thanks<br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Here’s a quick patch for this (<a href="https://reviews.llvm.org/D48850" class="">https://reviews.llvm.org/D48850</a>)</div><div class=""><br class=""></div><div class="">Thanks</div><div class="">Aditya</div><div class=""><br class=""></div></div>_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class=""></div></blockquote></div><br class=""></div></div></div></div></div>_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>