<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Sat, Feb 23, 2013 at 1:53 AM, Daniel Dunbar <span dir="ltr"><<a href="mailto:daniel@zuster.org" target="_blank">daniel@zuster.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="im">On Fri, Feb 22, 2013 at 1:29 AM, Alexey Samsonov <span dir="ltr"><<a href="mailto:samsonov@google.com" target="_blank">samsonov@google.com</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
  Hi Daniel,<br>
<br>
  Thanks for pointing out at llvm_use_intel_jitevents! I think we can benefit from adding a build configuration options that would tell<br>
  the build system to build LLVM/Clang under ASan/MSan/whatever. Then we can setup the correct compile flags, alter llvm-lit options<br>
  etc.<br>
<br>
  Still, I think this is somewhat orthogonal to this patch: we want to mark certain tests as "xfailing" under ASan, not "unsupported".<br>
  It's also good if we have per-test granularity instead of per-directory offered by lit.site.cfg (which is far less discoverable).<br>
<br>
  Probably, there is another way to achieve the goal - specify "asan" in --param flag, but this would also require untrivial<br>
  changes to lit to make it respect --param values in XFAIL: lines.<br></blockquote><div><br></div></div></div></div></div></blockquote><div><br></div><div style>Ok, I looked at tests/lit.cfg and got your point :) As it's convenient for us to define a configuration option of the form "LLVM_USE_SANITIZER", we may</div>
<div style>later pass necessary values to lit either via --param or using configurable tests/<a href="http://lit.site.cfg.in">lit.site.cfg.in</a>. I'll revisit this patch later. Thanks!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><div></div></div><div>That's not exactly what I meant. The way I envision things to work is that --param is used to pass in parameters to the test suite configuration. It's up to the individual test suite logic to then use those parameters to set features appropriately.</div>

<div><br></div><div>So, the way to do this just using --param is to require something like "--param=asan_enabled", and then in LLVM's lit.cfg add:</div><div>--</div><div>if lit.params.get('asan_enabled'):</div>

<div>  config.available_features.add(...)</div><div>--</div><div><br></div><div>The goal is that the test suite configuration file has precise control over the features, and user's can't munge them directly except by using test-suite ordained parameters.</div>

<div><br></div><div>The reason why I want this division is that in the long term I hope to allow test suites to declare the options they accept more explicitly, so that users (and developers) can see precisely what knobs and switches the test suite honor.</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div> - Daniel</div></font></span><div class="im"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
  P.S. One more random crazy idea: we can later pull --vg and --vg-leak under --exec-feature flag :)<br>
<br>
<a href="http://llvm-reviews.chandlerc.com/D413" target="_blank">http://llvm-reviews.chandlerc.com/D413</a><br>
</blockquote></div></div><br></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Alexey Samsonov, MSK</div>
</div></div>