<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Apr 27, 2016, at 12:57 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" class="">chandlerc@google.com</a>> wrote:<br class=""><div><blockquote type="cite" class="">Perhaps this is the intent, but I’d suggest specifically scoping the project to being “runtime” libraries specifically: things like math libraries are great to have, but something like a suite of auto-parallelization passes should be in another subproject.<br class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">Thing is, math libraries are often classified as not being "runtime" libraries. There is essentially a stricter definition of "runtime library" that means a library which is *only* called by the compiler, not by users, ever.</div><div class=""><br class=""></div><div class="">Anyways, I'm fine with using the term "runtime" and suffix "rt" provided we make it clear that it's OK if the library API is actually a user-facing API and it just has some other compiler involvement (like being implemented using LLVM-specific extensions).</div></div></div></div></blockquote><div><br class=""></div><div>Oh ok, I see the distinction you’re making here. Maybe a “lib” suffix, like “parallel_lib”? The concern I have is that “utils” is just completely vacuous.</div><div><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> This avoids some license issues we currently have,</blockquote><div class=""><br class=""></div><div class="">Do note that the proposal is not to try to avoid these and to allow linking the Support library into these runtime libraries. Currently, for several of the candidates, they really need substantial basic infrastructure that should be shared with other LLVM projects. So we'll eventually need a proper solution for using those from runtime libs. =/ We're just OK living with these libs falling under the LLVM license for now.</div></div></div></blockquote><br class=""></div><div>Ok!</div><div><br class=""></div><div>-Chris</div><br class=""></body></html>