<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 7, 2013 at 1:52 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</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"><div class=""><div class="h5">On Mon, Jan 7, 2013 at 1:46 PM, Daniel Dunbar <<a href="mailto:daniel@zuster.org">daniel@zuster.org</a>> wrote:<br>

><br>
><br>
><br>
> On Mon, Jan 7, 2013 at 1:14 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
>><br>
>> On Mon, Jan 7, 2013 at 12:58 PM, Daniel Dunbar <<a href="mailto:daniel@zuster.org">daniel@zuster.org</a>> wrote:<br>
>> > To weigh in here...<br>
>> ><br>
>> ><br>
>> > On Thu, Jan 3, 2013 at 8:15 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> +Daniel & Michael who work on the LNT infrastructure & might have some<br>
>> >> thoughts on the differences & their merits & motivations.<br>
>> >><br>
>> >> On Thu, Jan 3, 2013 at 4:05 AM, Renato Golin <<a href="mailto:renato.golin@linaro.org">renato.golin@linaro.org</a>><br>
>> >> wrote:<br>
>> >> > David,<br>
>> >> ><br>
>> >> > I got some more work on the Livermore Loops and I found out that the<br>
>> >> > issue<br>
>> >> > is the difference in the parameters between a single step and a multi<br>
>> >> > step<br>
>> >> > compilation.<br>
>> >><br>
>> >> Thanks for the investigation.<br>
>> >><br>
>> >> > When you compile "clang kernel06.c" it works fine, but when you get<br>
>> >> > all<br>
>> >> > steps (clang -emit-llvm + llvm-as + opt + llc etc), the defaults<br>
>> >> > options<br>
>> >> > of<br>
>> >> > each and how they interact is showing a bug in the code generated.<br>
>> >><br>
>> >> Sounds quite plausible.<br>
>> >><br>
>> >> > This difference is due to the fact that I'm running the test-suite<br>
>> >> > using<br>
>> >> > LNT, while the build bots are running it using Make directly. I'd<br>
>> >> > expect<br>
>> >> > them both to be the same, but apparently they're quite different in<br>
>> >> > what<br>
>> >> > kind of parameters they use, passes they test and results they get.<br>
>> >> ><br>
>> >> > I think there are two courses of action here:<br>
>> >> ><br>
>> >> > 1. Identify the issue, isolate the case and create a bug to resolve<br>
>> >> > later.<br>
>> >> > 2. Make sure LNT does exactly what the build bots are doing<br>
>> >><br>
>> >> Part of the issue here is whether or not the Make-based execution is<br>
>> >> still maintained/valued. I'm getting the impression that the LNT<br>
>> >> execution may be already, or be becoming, the standard way to run the<br>
>> >> test suite even when not gathering perf statistics. Michael/Daniel -<br>
>> >> is that the case?<br>
>> ><br>
>> ><br>
>> > Well, the distinction isn't really between LNT and non-LNT, its between<br>
>> > the<br>
>> > TEST=nightly and TEST=simple style supported by the Makefiles. LNT uses<br>
>> > the<br>
>> > TEST=simple style and that is all I care to support.<br>
>><br>
>> Fair enough, though that's sort of what I was getting at in a way:<br>
>> whatever way LNT is driving the test-suite is, essentially, the only<br>
>> supported way. Sure we can have non-LNT bots (not ideal, perhaps -<br>
>> still another path to maintain/possibly diverge by accident) but they<br>
>> certainly shouldn't be using anything other than the way LNT uses the<br>
>> test-suite (ie: TEST=simple).<br>
>><br>
>> Can we kill TEST=nightly, then, since it's just an<br>
>> untested/unsupported trap? Or do you know of users that have a need<br>
>> for this?<br>
><br>
><br>
> It's untested, but as supported as anything else (I try not to break it, and<br>
> will fix bugs in it).<br>
><br>
> And yes, there are still users that use this regularly. Most of that is<br>
> probably habit among old-school LLVMers, but it's still useful when you want<br>
> to do direct A/B testing of optimizer changes (support for things like<br>
> OPTBETA and LLCBETA), or when you want to test a change without requiring a<br>
> compiler rebuild.<br>
><br>
> For example, we still don't have very good support in the compiler for<br>
> tweaking various parts of the compilation process (for example, running with<br>
> a custom pass list), so the easiest way to test addition of a new pass may<br>
> still be using TEST=nightly.<br>
><br>
> My natural tendency is towards "if it isn't broke, don't kill it", and not<br>
> to try and remove it until we have a new separate way of running the test<br>
> suite outside of the Makefiles.<br>
><br>
>><br>
>> ><br>
>> > Historically, the old way of testing (TEST=nightly) used the various<br>
>> > LLVM<br>
>> > tools to effect a compilation because there weren't compilers that<br>
>> > worked.<br>
>> > However, this is a bad way to "test" the product that most users<br>
>> > actually<br>
>> > care about, which is the compiler.<br>
>> ><br>
>> > With TEST=simple, all the compilation is done using the compiler just as<br>
>> > an<br>
>> > end user would. If you want LTO, the right way to get it is to use the<br>
>> > compilers support for LTO. This is how we test LTO internally. I've<br>
>> > never<br>
>> > tried to get LTO working on Linux, but it should be possible using the<br>
>> > gold<br>
>> > plugin and passing the right compiler options.<br>
>> ><br>
>> >> If so, should we rip out the direct Make execution, or do something to<br>
>> >> otherwise warn/disable it?<br>
>> ><br>
>> ><br>
>> > Per my other thread polling users of the test-suite, there are still<br>
>> > people<br>
>> > who use the Makefiles to do more custom things. I personally would love<br>
>> > to<br>
>> > deprecate them completely, but they do support some useful workflows.<br>
>> ><br>
>> > My ideal would be:<br>
>> > 1. Migrate LNT to drive the test-suite using a more sane mechanism (not<br>
>> > a<br>
>> > glob of Makefiles). I would like the "more sane mechanism" to be<br>
>> > lit-based.<br>
>> > 2. Maybe do some work to make using lit to drive the test-suite more<br>
>> > convenient and hopefully support some of the useful workflows the<br>
>> > Makefiles<br>
>> > support with less of the crap.<br>
>> > 3. Deprecate the Makefiles, or at least let the die through lack of<br>
>> > maintenance.<br>
>> ><br>
>> > Does that answer the parts you wanted my input on?<br>
>><br>
>> More or less, I suppose I wouldn't mind an opinion on the "should we<br>
>> kill off/migrate bots from test-suite invocation to LNT?" issue too.<br>
>> (my assumption is that your answer to that is "yes", but just want to<br>
>> be clear)<br>
><br>
><br>
> Yes, definitely.<br>
<br>
</div></div>Hmm, this seems at odds with your above opinion on not killing<br>
TEST=nightly, though. If we actively migrate bots away from<br>
TEST=nightly we're going to break it (indeed we Renato already has<br>
which is how this thread came up).</blockquote><div><br></div><div>By "not breaking it", I meant the infrastructure of it, not whether or not the tests work or not.</div><div><br></div><div>As for the actual LLVM bug, we should probably try and get an LTO LNT bot up, though, which would most likely hit the same bug.<br>
</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"> If it's broken that, I would think,<br>

is going to cause some confusion/problems for those using it &<br>
expecting things to pass. Is your impression/experience that those<br>
running this manually for custom testing aren't too concerned about<br>
spurious failures?<br></blockquote><div><br></div><div style>In my mind, I don't necessarily think "its broken" makes sense in this context. It's not TEST=nightly that is broken, it is the compiler in the context of a one architecture, one set of compile options, etc.</div>
<div style><br></div><div style>I expect/hope developers to be aware that compiler bugs may only manifest under a very specific set of circumstances, and so they need to run their tests in the same way as the buildbots if they want results to match. And I hope most core LLVM developers realize that the way TEST=nightly ends up building binaries is very different from using the compiler directly, but if not most of them figure this out very quickly in practice.</div>
<div style><br></div><div style>I see LNT + TEST=simple as the "right way" to do large scale testing w/ the test suite and buildbots, but if developers want to use TEST=nightly for experiments or development its still there. I have actively tried to encourage people to switch over to using TEST=simple when possible, but its hard to get people to change existing workflows if there isn't a clear benefit.</div>
<div style><br></div><div style> - Daniel</div><div style> </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>
- David<br>
</font></span><div class=""><div class="h5"><br>
><br>
>  - Daniel<br>
><br>
>><br>
>><br>
>> - David<br>
>><br>
>> ><br>
>> >  - Daniel<br>
>> ><br>
>> >><br>
>> >> > I'm working on item 1 right now, not sure how item 2 can be solved...<br>
>> >> ><br>
>> >> > Of course, the fact that it's the not same flow meant we caught a bug<br>
>> >> > in<br>
>> >> > LLVM, but that's bound to create more confusion and broken commits,<br>
>> >> > which is<br>
>> >> > worse in the long run.<br>
>> >><br>
>> >> Yeah, unless there's some strong/specific motivation for this I'd be<br>
>> >> in favor of removing the difference (or removing the Make-based<br>
>> >> execution entirely)<br>
>> >><br>
>> >> > Also, if we're not running LNT as often as buildbots, the benefit of<br>
>> >> > having<br>
>> >> > them different is sporadic at best.<br>
>> >><br>
>> >> we're running both pretty regularly, I think - if anything I suspect<br>
>> >> we might be running LNT on more configurations than the Make-based<br>
>> >> execution (except that on some LNT runners we're multisampling, so<br>
>> >> it's slower)<br>
>> >><br>
>> >> > When I set up some tests to run on ARM I have done both direct and<br>
>> >> > multi-step, to make sure they were generating the same code and in<br>
>> >> > many<br>
>> >> > cases I found that the order in which the passes were executed was<br>
>> >> > breaking<br>
>> >> > some tests.<br>
>> >> ><br>
>> >> > We managed to get the EDG bridge to set it up in the same way as the<br>
>> >> > multi-pass would, so we would get similar results, but it doesn't<br>
>> >> > seem<br>
>> >> > to be<br>
>> >> > the case with clang.<br>
>> >> ><br>
>> >> > cheers,<br>
>> >> > --renato<br>
>> ><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>