<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Feb 24, 2016 at 1:26 PM Matthias Braun <<a href="mailto:matze@braunis.de">matze@braunis.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I don't really care where the repository is located, but I do have some comments on the future test-suite directions:</div></div></blockquote><div><br></div><div>Just as a meta-point, I don't want to conflate any of this with a specific design direction. I'm really focused on "where is it hosted" as a simplifying thing for the projects infrastructure.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div></div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Feb 24, 2016, at 12:57 PM, Chandler Carruth via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br><div><div dir="ltr">Subject kinda says it all. Here is my rationale:<div><br></div><div>The test-suite is really weird relative to the rest of the LLVM project:</div><div>1) It contains all manner of crazily licensed code.<br></div></div></div></blockquote></div></div><div style="word-wrap:break-word"><div><div>That's indeed a good reason to move the repository away.</div></div></div><div style="word-wrap:break-word"><div><div><br></div><blockquote type="cite"><div><div dir="ltr"><div>2) We don't really care about the history at all. Any concerns around linear history or bisection are pretty much irrelevant.</div></div></div></blockquote></div></div><div style="word-wrap:break-word"><div><div>We do care about the history. Sometimes benchmarks get fixed or tweaked which may change the results, we should be able to dig into the history to see what happened when. In any way retaining the history wouldn't be a problem, would it?</div></div></div></blockquote><div><br></div><div>See John's response, and sorry for the broad statement.</div><div><br></div><div>I meant, we don't care about a shared linear monotonic history with the rest of the compiler that we can bisect across simultaneously.</div><div><br></div><div>Clearly we still want version control!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><blockquote type="cite"><div><div dir="ltr"><div>3) We don't ever plan to have LLVM code move into or out from the test-suite</div></div></div></blockquote></div></div><div style="word-wrap:break-word"><div><div>I could actually see moving llvm code into the test-suite (we already use lit code from llvm) but indeed move code out of the testsuite into llvm I don't foresee happening.</div></div></div></blockquote><div><br></div><div>Well, I think it might make sense to separate the LLVM code *used* by the test suite from the test suite itself. I'd be happy to keep that code in the LLVM repository to the extent possible (perhaps with expanded stuff under utils/...).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div dir="ltr"><div>4) Its already big, and really should be much bigger. We shouldn't have incentives to keep stuff out of the test suite because of size, hosting cost, or anything else.</div></div></div></blockquote></div></div><div style="word-wrap:break-word"><div><div>I agree with the goal of having a big test-suite. However I think there is a point where we should rather strive to have a stable base system for building and running tests, etc. and then have the actual benchmarks/tests being modules on top of that. We already have that situation today with External/SPEC* and I think it would be a good idea to have a mode where you just checkout more benchmarks into a test-suite subdirectory and they are automatically recognized and used (in fact that is something on my TODO list though at a very low position).</div></div></div></blockquote><div><br></div><div>No argument to me about needed better organization, modularity and such. And we definitely need to have reasonably small slices that we *really* care about.</div><div><br></div><div>I think its useful to the extent possible to provide a common repository so that folks don't have to aggregate too many things just so that we can have more productive discussions ("Well, where did you pull benchmark Whizzbang from? Oh, I have a different variant of it, so that's why I don't see that regression").</div><div><br></div><div>But none of that should argue against better modularity and extensibility in it</div></div></div>