<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 7, 2013 at 1:14 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">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>> 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 all<br>
>> > steps (clang -emit-llvm + llvm-as + opt + llc etc), the defaults 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 using<br>
>> > LNT, while the build bots are running it using Make directly. I'd expect<br>
>> > them both to be the same, but apparently they're quite different in 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 the<br>
> TEST=nightly and TEST=simple style supported by the Makefiles. LNT uses the<br>
> TEST=simple style and that is all I care to support.<br>
<br>
</div></div>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></blockquote><div><br></div><div style>It's untested, but as supported as anything else (I try not to break it, and will fix bugs in it).</div><div style><br></div><div style>And yes, there are still users that use this regularly. Most of that is probably habit among old-school LLVMers, but it's still useful when you want to do direct A/B testing of optimizer changes (support for things like OPTBETA and LLCBETA), or when you want to test a change without requiring a compiler rebuild.</div>
<div style><br></div><div style>For example, we still don't have very good support in the compiler for tweaking various parts of the compilation process (for example, running with a custom pass list), so the easiest way to test addition of a new pass may still be using TEST=nightly.</div>
<div style><br></div><div style>My natural tendency is towards "if it isn't broke, don't kill it", and not to try and remove it until we have a new separate way of running the test suite outside of the Makefiles.<br>
</div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
><br>
> Historically, the old way of testing (TEST=nightly) used the various LLVM<br>
> tools to effect a compilation because there weren't compilers that worked.<br>
> However, this is a bad way to "test" the product that most users actually<br>
> care about, which is the compiler.<br>
><br>
> With TEST=simple, all the compilation is done using the compiler just as 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 never<br>
> tried to get LTO working on Linux, but it should be possible using the 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 people<br>
> who use the Makefiles to do more custom things. I personally would love 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 a<br>
> glob of Makefiles). I would like the "more sane mechanism" to be 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 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>
</div>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></blockquote><div><br></div><div style>Yes, definitely.</div><div style><br></div><div style> - Daniel</div><div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<span class="HOEnZb"><font color="#888888"><br>
- David<br>
</font></span><div class="HOEnZb"><div class="h5"><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 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 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 seem<br>
>> > to be<br>
>> > the case with clang.<br>
>> ><br>
>> > cheers,<br>
>> > --renato<br>
><br>
><br>
</div></div></blockquote></div><br></div></div>