<div dir="ltr">This would require threading the value through some LLVMTargetMachine functions, at the least.  Do we still lock and check the env. var. if the given value is NULL?  Or just do away with the default coming from the env. var?</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 23, 2013 at 2:30 PM, Sean Silva <span dir="ltr"><<a href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</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 Thu, May 23, 2013 at 8:13 AM, Justin Holewinski <span dir="ltr"><<a href="mailto:justin.holewinski@gmail.com" target="_blank">justin.holewinski@gmail.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"><div dir="ltr">That sounds like a missed multi-threading issue with LLVM.  I can't imagine why the user should be forced to serialize creation of MCContext objects. I would suggest filing a bug for this.  A simple lock probably wouldn't be too detrimental to performance here, since MCContext objects shouldn't be created too often.</div>


<div class="gmail_extra"><div><div><br></div></div></div></blockquote></div><div>The deeper question is why we are even checking a "global" here in the first place? It goes against LLVM's library-based design. So I don't think introducing locking around this is the "right" solution. Can we just make this value an argument to the constructor?</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>-- Sean Silva</div></font></span></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div>
</div>