<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 10, 2016 at 11:41 AM, Chris Bieneman via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">I probably should have stated this in my last email. I see all three of these initiatives as separate restructuring changes. None of them should need to be tied to each other or block the others.<div><br></div><div><br></div><div><div><span class=""><blockquote type="cite"><div>On Jun 10, 2016, at 11:23 AM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Jun 10, 2016 at 10:52 AM Chris Bieneman via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>It seems to me that the feedback here has been generally positive, but a lot of different ideas have been added to the mix.</div><div><br></div><div>To focus conversation and move things along I'm going to provide a summary of changes with proposals for rollout.</div><div><br></div><div>Splitting Compiler-RT</div></div></blockquote><div><br></div><div>Note that none of the main sanitizer developers have really chimed in here... It'd be good to actually talk to them first. =]</div></div></div></div></blockquote><div><br></div></span><div>Agreed. My hope is that some of them may see this thread and chime in.</div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span style="line-height:1.5">If we want to split compiler-rt, which I think makes a lot of sense, I think the best path forward is to copy the trunk (via svn cp). Copying the branch is the best way to preserve the history and workflows.</span><br></div><div><br></div><div>For naming purposes I would suggest retaining the compiler-rt name for the builtin libraries, and having a repository named sanitizer-rt for the sanitizer libraries (this is of course just a suggestion, feel free to bike shed).</div></div></blockquote><div><br></div><div>I would very much like a more specific name than 'compiler-rt'. The genericness of that name is what led to some of the confusion today I suspect.</div><div><br></div><div>I would also suggest not having a hyphen in the name which makes python and other systems sad (I don't understand why, and I've given up fighting this battle).</div><div><br></div><div>I think you already used the word that would best describe this: "builtin libraries".</div><div><br></div><div>However, I'm not sure if splitting (at this point) makes sense. Maybe it does, but its seems fuzzy to me. The "builtins" will still be a collection of multiple runtime libraries, all tied to builtin compiler features. Some will be C/C++ features (the libgcc alternative for EH, type info, and math stuff). Some will be profiling features and some will be sanitizer features. I think having a separate repository for the profiling runtimes would probably be overkill. Maybe sanitizers are big enough to split out, but it seems iffy to me. I think the big thing that would help would just be better organization *within* the tree to clearly name the profile, language builtins, and sanitizer components.</div></div></div></div></blockquote><div><br></div></span><div>I think the fundamental distinction needs to be following dependency graphs because if we don’t get rid of the circular dependency in bootstrapping there is no reason to make any changes.</div></div></div></div></blockquote><div><br></div><div><div>+1 for what Chandler said here.</div><div><br></div><div>I don't think CMake itself per se cares about actual VCS repo breakdown. It should be possible to bring sanity without any change to VCS structure.</div><div><br></div><div>-- Sean Silva</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><div> The builtin, profile and safestack library are all static archives, so they don’t actually require a built libcxx (although they can rely on the headers). They can all be treated as “builtins”.</div><div><br></div><div>The sanitizer runtimes produce dylibs that must be linked against libcxx, so they cannot be treated as builtins. IMO, following the general rule of thumb “does this need a linker” is probably close to the right bar.</div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Either way, I'd call the thing with profiling and language builtin runitmes "builtins" before "compiler"-anything.</div><div><br></div><div><span style="line-height:1.5"> </span><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>Breaking out testing tools</div><div><br></div><div>As I started looking into breaking out the testing tools I realized it is *much* more complicated than I had first thought. I do think that it is a good idea to do this, but it is going to be a bigger change than I had originally thought.</div></div></blockquote><div><br></div><div>FWIW, I'm not at all convinced this is a good idea yet. It has some appeal, but we've tried this before and it created confusion bordering on chaos. I would definitely decouple these things.</div></div></div>
</div></blockquote><br></span></div><div>I’ve been discussing this all morning in the halls, and most people in our office seem to think it would be neat, but is a huge (and separate) project.</div><span class=""><font color="#888888"><div><br></div><div>-Chris</div><br></font></span></div></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>