<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">llvm-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 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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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><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:0 0 0 .8ex;border-left:1px #ccc solid;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>