<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 21, 2016 at 10:17 AM, Davide Italiano via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">davide added a comment.<br>
<br>
I'm still convinced (for many reasons) that checking in a binary isn't a great option when we can use MC.<br>
I don't think "excessive dependencies like asm->llvm-mc->zlib" is a strong argument as we have them anyway.<br>
OTOH, using our tools instead of a binary allows:<br>
<br>
1. dogfooding (which might catch regression)<br></blockquote><div><br>Generally we try to separate which things are tested - granted that gets fuzzy with the tools we use for testing (so we want to use readobj to test some llvm-mc feature - so we can't isolate the testing of each entirely). If we're missing llvm-mc testing, we should add it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. easier changes in case something breaks in the toolchain (we don't need to generate the binary again, we can just change the test)<br></blockquote><div><br></div><div>I'm not quite following here - if something breaks in the toolchain why would we need to regenerate the llvm-readobj test? We might need to add new tests to make sure readobj can handle the new/different/possibly broken input in some sane way, but unless we discover that the original test was incorrect we shouldn't need to regenerate it, right?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. readability (you can read the ASM instead of a description). Maybe it's not the case but from time to time precompiled binaries lack a comment which describes how they've been generated, and comments and binary can get out of sync quickly.<br></blockquote><div><br>Then lets make sure we add/maintain the comments - part of code review, etc (in the same way that "don't use a binary test" would be code review feedback we'd provide if we went that way).<br><br>We certainly don't have hard and fast rules here (& for some tools like dwarfdump/readobj/etc we can be a bit lax on testing, treating them as just testing/dev tools, etc) - certainly there are varying opinions (eg: the use of llvm-mc in lld tests rather than the standalone object file format (json or whatever it was)) & we're always adjusting. So there's totally room to discuss/debate.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In other words, I'm always for using llvm-mc instead of a binary (unless there's a strong reason not to). I'd rather bit the bullet and implement the missing feature in the assembler instead of going through the binary route which may lead to bigger pain later (I had to generate again ~10 binaries in DebugInfo tests in order to fix a bug in the verifier recently).<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="http://reviews.llvm.org/D20273" rel="noreferrer" target="_blank">http://reviews.llvm.org/D20273</a><br>
<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div></div>