
<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="">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 class=""><br class=""></div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Jun 10, 2016, at 11:23 AM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" class="">chandlerc@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, Jun 10, 2016 at 10:52 AM Chris Bieneman via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></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" class=""><div class="">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 class=""><br class=""></div><div class="">To focus conversation and move things along I'm going to provide a summary of changes with proposals for rollout.</div><div class=""><br class=""></div><div class="">Splitting Compiler-RT</div></div></blockquote><div class=""><br class=""></div><div class="">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 class=""></div><div>Agreed. My hope is that some of them may see this thread and chime in.</div><br class=""><blockquote type="cite" class=""><div 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"><div style="word-wrap:break-word" class=""><div class=""><span style="line-height:1.5" class="">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 class=""></div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">I think you already used the word that would best describe this: "builtin libraries".</div><div class=""><br class=""></div><div class="">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 class=""></div><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. 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 class=""></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><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">Either way, I'd call the thing with profiling and language builtin runitmes "builtins" before "compiler"-anything.</div><div class=""><br class=""></div><div class=""><span style="line-height:1.5" class=""> </span><br class=""></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" class=""><div class="">Breaking out testing tools</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""></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><div><br class=""></div><div>-Chris</div><br class=""></div></body></html>