<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Apr 27, 2016 at 4:45 PM Jason Henline via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Maybe a “lib” suffix, like “parallel_lib”<br><div><br></div></div><div dir="ltr"><div>parallel_lib sounds good to me. Let's make that the proposed name rather than parallel_util.</div></div></blockquote><div><br></div><div>LGTM too.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr">On Wed, Apr 27, 2016 at 1:32 PM Chris Lattner <<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">On Apr 27, 2016, at 12:57 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>> wrote:<br></div><div style="word-wrap:break-word"><div><blockquote type="cite">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><div><div dir="ltr"><div class="gmail_quote"><div><br></div><div>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><br></div><div>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></div></div></div><div style="word-wrap:break-word"><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></div><div style="word-wrap:break-word"><div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div> </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><br></div><div>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></div></div><div style="word-wrap:break-word"><div></div><div>Ok!</div></div><div style="word-wrap:break-word"><div><br></div><div>-Chris</div><br></div></blockquote></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>