<div dir="ltr">YAML Parser is only used by things that need to parse YAML, which while in principle might seem generic, is actually only used by a small number of tools. Besides, if you're bringing in YAML to parse something, then you're probably linking against some library like libObject, which will in turn link against Support (as I'm referring to it in this thread, not as it exists today).<div><br></div><div>It might turn out though that in practice it would be hard to keep it out of Base, because for example even Statistic uses it for dumping. I did a quick search and sadly it seems like a lot of libraries include YAML support directly in the library rather than in the tool that dumps the library.</div><div><br></div><div>That said, it would be nice if at all possible the barrier to entry for getting something into Base were higher and stricter than the barrier to entry for getting something into Support. So whenever possible we should err on the side of keeping stuff out of base.</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, May 29, 2017 at 10:22 AM Mehdi AMINI <<a href="mailto:joker.eph@gmail.com">joker.eph@gmail.com</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"><div class="gmail_extra"><div class="gmail_quote">2017-05-29 9:25 GMT-07:00 Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><div><div class="gmail_quote"><div>On Sun, May 28, 2017 at 8:54 PM Mehdi AMINI 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev <span><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span>:<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>Changing a header file somewhere and having to spend 10 minutes waiting for a build leads to a lot of wasted developer time.<div><br></div><div>The real culprit here is tablegen. Can we split support and ADT into two - the parts that tablegen depends on and the parts that it doesn't?</div></div></blockquote><div></div></div><div><br></div></div><div><div>Splitting ADT just based on tablegen usage seems dubious to me. If we need to go this route, I'd replace as many uses of ADT data structure with STL ones to begin with to reduce the surface.</div></div></blockquote><div><br></div></div></div></span><div><div class="gmail_quote"><div>Tablegen would not need to determine WHERE to split, it would just motivate the why.</div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Well even the why :)</div><div>(note I was mentioning ADT and not Support above).</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_quote"><div> It's obvious just from looking at Support's include directory though that a lot of stuff in there doesn't belong together. A quick look over the include directory already suggests a split into "broadly useful stuff" and "narrowly useful stuff"</div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I agree, Support is a mess IMO (we have target specific stuff here just for the sake of sharing code with clang AFAIK) and I'm not sure anyone would oppose to split it. Ideally the way I would split it would be such that it could (at some point) be useful outside of LLVM (just like ADT), so one main criteria could be "could this component of Support be useful outside of LLVM (and its subprojects)".</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_quote"><div><br></div><div>Broadly useful stuff:</div><div>AlignOf</div><div>Allocator</div><div>ArrayRecycler</div><div>Atomic</div><div>AtomicOrdering</div><div>Capacity</div><div>Casting</div><div>Chrono</div><div>circular_raw_ostream</div><div>COM.h</div><div>CommandLine.h</div><div>Compiler.h</div><div>ConvertUTF.h</div><div>CrashRecoveryContext.h</div><div>DataExtractor.h</div><div>Debug.h</div><div>Endian.h</div><div>EndianStream.h</div><div>Errc.h</div><div>Errno.h</div><div>Error.h</div><div>ErrorHandling.h</div><div>ErrorOr.h</div><div>FileOutputBuffer.h</div><div>FileSystem.h</div><div>FileUtilities.h</div><div>Format*.h</div><div>GlobPattern.h</div><div>Host.h</div><div>JamCRC.h</div><div>KnownBits.h</div><div>LineIterator.h</div><div>Locale.h</div><div>ManagedStatic.h</div><div>MathExtras.h</div><div>MD5.h</div><div>Memory.h</div><div>MemoryBuffer.h</div><div>Mutex.h</div><div>MutexGuard.h</div><div>NativeFormatting.h</div><div>Options.h</div><div>Parallel.h</div><div>Path.h</div><div>PointerLikeTypeTraits.h</div><div>PrettyStackTrace.h</div><div>Printable.h</div><div>Process.h</div><div>Program.h</div><div>RandomNumberGenerator.h</div><div>raw_os_ostream.h</div><div>raw_ostream.h</div><div>raw_sha1_ostream.h</div><div>Recycler.h</div><div>RecyclingAllocator.h</div><div>Regex.h</div><div>RWMutex.h</div><div>SaveAndRestore.h</div><div>ScaledNumber.h</div><div>SHA1.h</div><div>Signals.h</div><div>StringPool.h</div><div>StringSaver.h</div><div>SwapByteOrder.h</div><div>SystemUtils.h</div><div>thread.h</div><div>Threading.h</div><div>ThreadLocal.h</div><div>ThreadPool.h</div><div>Timer.h</div><div>TrailingObjects.h</div><div>Unicode.h</div><div>UnicodeCharRanges.h</div><div>UniqueLock.h</div><div>Watchdog.h</div><div>Win64EH.h</div><div>WindowsError.h</div><div>xxhash.h</div><div><br></div><div><br></div><div>Narrowly useful stuff:</div><div>AArch64TargetParser.def</div><div>ARMAttributeParser.h</div><div>ARMBuildAttriubtes.h</div><div>ARMEHABI.h</div><div>ARMTargetParser.def</div><div>ARMWinEH.h</div><div>Binary*Stream*.h</div><div>BlockFrequency.h</div><div>BranchProbability.h</div><div>CachePruning.h</div><div>CBindingWrapping.h</div><div>CodeGen.h</div><div>CodeGenCWrappers.h</div><div>COFF.h</div><div>Compression.h</div></div></div><div><div class="gmail_quote"><div><div>DebugCounter.h</div>DotGraphTraits.h</div><div>Dwarf.def</div><div>Dwarf.h</div><div>DynamicLibrary.h</div><div>ELF.h</div><div>GCOV.h</div><div>GenericDomTree.h</div><div>GenericDomTreeConstruction.h</div><div>GraphWriter.h</div><div>LEB128.h</div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>LEB128.h seems quite generic.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_quote"><div>LockFileManager.h</div><div>LowLevelTypeImpl.h</div><div>MachO.def</div><div>MachO.h</div><div>MipsABIFlags.h</div><div>OnDiskHashTable.h</div><div>PluginLoader.h</div><div><div>Registry.h</div><div>ScopedPrinter.h</div>SMLoc.h</div><div>Solaris.h</div><div>SourceMgr.h</div><div>SpecialCaseList.h</div><div>TargetParser.h</div><div>TargetRegistry.h</div><div>TargetSelect.h</div><div>TarWriter.h</div><div>ToolOutputFile.h</div><div>TrigramIndex.h</div><div>TypeName.h</div><div>Valgrind.h</div><div>Wasm.h</div><div>YAMLParser.h</div><div>YAMLTraits.h</div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>YAML Parser as well.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>-- </div><div>Mehdi</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_quote"><div><br></div><div><br></div><div>So, as a very crude first attempt, you call the first group of stuff "Base", the second group "Support", and add a dependency from Support to Base. This has nothing to do with tablegen, btw, and tablegen would still probably depend on Support even after this separation, but it makes sense even from a high level layering perspective (IMO)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><div><div></div><div><br></div><div><br></div><div class="gmail_extra"><div class="gmail_quote"></div></div></div><div><div class="gmail_extra"><div class="gmail_quote">2017-05-28 8:25 GMT-07:00 Krzysztof Parzyszek via llvm-dev <span><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span>:<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"><span class="m_7461767555009368867m_-2402408957551649025m_1774889128856250233m_-2104759218787413549gmail-">On 5/26/2017 7:59 PM, Zachary Turner via llvm-dev 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">
It's that TableGen depends on Support, so if you change one file in<br>
support, support gets recompiled into a new static archive, which<br>
triggers a rerun of tablegen on all the tablegen inputs, which is<br>
extremely slow.<br>
</blockquote>
<br></span>
What exactly is extremely slow? In my experience TableGen itself takes a negligible amount of time compared to the rest of the build. This is particularly true in cases when something in Support or ADT is modified, as this usually triggers recompilation of large parts of LLVM.<br></blockquote><div><br></div></div></div></div><div><div class="gmail_extra"><div class="gmail_quote"><div>Tablegen built in debug is really slow though, I remember an out-of-tree backend where running llvm-tblgen was taking up to 5 min per file!<div>The CMake option LLVM_OPTIMIZED_TABLEGEN helps a lot with this. Otherwise LLVM_TABLEGEN is even more efficient, but it's a double-edged sword.</div><div><br></div><div>But we could also use the diff-and-copy approach not on the tablegen output but on the llvm-tblgen binary itself, that way we wouldn't re-run it when it does not change itself (I'm not sure why CMake does not use this strategy by default for any file including .o and .a?).</div></div></div></div></div><div><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>-- </div><div>Mehdi</div><div><br></div></div></div></div></span><span>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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>
</span></blockquote></div></div></div>
</blockquote></div></div></div></blockquote></div>