<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div>I would describe it from this angle: LLVM is layered just fine. Usually the layering is enforced as we don't link all libraries to all targets and you will notice missing symbols if you violate it. It just happens that you can violate the layering with header-only implementations of features that are not catched this way and sure enough we a handful of cases that violate the layering this way as David nicely explained here.</div><div><br class=""></div><div>I don't think there is a reason not to fix those layering violations. We just need a plan on how to fix them.</div><div><br class=""></div><div>- Matthias</div><div><br class=""></div><div><blockquote type="cite" class=""><div class="">On Jan 16, 2018, at 10:15 AM, Robinson, Paul via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="WordSection1" style="page: WordSection1; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: "Times New Roman", serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">I have found layering to be a particularly useful and beneficial model in past large software projects.<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: "Times New Roman", serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""><o:p class=""> </o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: "Times New Roman", serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">Is LLVM's layering actually written down anywhere? Last time I went looking, there was nothing. If there's no spec, there's no verifiable conformance; you have to guess based on what other files do.<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: "Times New Roman", serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">--paulr<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: "Times New Roman", serif;" class=""><a name="_MailEndCompose" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""><o:p class=""> </o:p></span></a></div><div style="border-style: none none none solid; border-left-width: 1.5pt; border-left-color: blue; padding: 0in 0in 0in 4pt;" class=""><div class=""><div style="border-style: solid none none; border-top-width: 1pt; border-top-color: rgb(181, 196, 223); padding: 3pt 0in 0in;" class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: "Times New Roman", serif;" class=""><b class=""><span style="font-size: 10pt; font-family: Tahoma, sans-serif;" class="">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif;" class=""><span class="Apple-converted-space"> </span>llvm-dev [<a href="mailto:llvm-dev-bounces@lists.llvm.org" class="">mailto:llvm-dev-bounces@lists.llvm.org</a>]<span class="Apple-converted-space"> </span><b class="">On Behalf Of<span class="Apple-converted-space"> </span></b>David Blaikie via llvm-dev<br class=""><b class="">Sent:</b><span class="Apple-converted-space"> </span>Tuesday, January 16, 2018 9:22 AM<br class=""><b class="">To:</b><span class="Apple-converted-space"> </span>llvm-dev; Richard Smith; Chandler Carruth; Reid Kleckner<br class=""><b class="">Subject:</b><span class="Apple-converted-space"> </span>[llvm-dev] Layering Requirements in the LLVM Coding Style Guide<o:p class=""></o:p></span></div></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: "Times New Roman", serif;" class=""><o:p class=""> </o:p></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: "Times New Roman", serif;" class="">Context: I've been looking at experimenting with using Modular Code Generation (My talk at last year's LLVM dev meeting <a href="https://www.youtube.com/watch?v=lYYxDXgbUZ0" style="color: purple; text-decoration: underline;" class="">https://www.youtube.com/watch?v=lYYxDXgbUZ0</a> is about the best reference at the moment) when building the LLVM project, as a good experiment for the feature. This can/does enforce a stronger layering invariant than LLVM has historically been enforced. So I'm curious to get buy-in and maybe document this if it's something people like the idea of.<br class=""><br class="">I'm starting this discussion here rather than in an actual code review on llvm-commits since it seems like it could do with a bit of a wider discussion, but once/if the general direction is agreed on, I'll send a patch for review of specific wording for the LLVM Coding Standards.<br class=""><br class=""><br class="">Currently the<span class="Apple-converted-space"> </span><a href="https://llvm.org/docs/CodingStandards.html" style="color: purple; text-decoration: underline;" class="">LLVM Coding Standards</a> doesn't say much/anything about layering.<span class="Apple-converted-space"> </span><a href="https://llvm.org/docs/CodingStandards.html#a-public-header-file-is-a-module" style="color: purple; text-decoration: underline;" class="">'A Public Header File<span class="Apple-converted-space"> </span><b class="">is</b><span class="Apple-converted-space"> </span>a Module'</a> section talks about modules of functionality, mostly trying to describe why a header file should be self contained - but uses anachronistic language about modules that doesn't line up with the implicit or explicit modules concepts in use today, I think.<br class=""><br class="">I propose making this wording a bit more explicit, including:<br class=""><br class="">1) Headers should be standalone (include all their dependencies - this is mentioned in the "is a Module" piece, by way of a technique to help ensure this, but not explicit as a goal itself).<br class=""><br class="">2) Files intended to be included in a particular context (that aren't safe/benign to include multiple times, in multiple .cpp files, etc) should use a '.inc' or '.def' (.def specifically for those "define a macro, include the header which will reference that macro" style setups we have in a few places).<br class=""><br class="">And the actual layering issue:<br class="">3) Each library should only include headers or otherwise reference entities from libraries it depends on. Including in headers and inline functions. A simple/explicit way to put this: every inline function should be able to be moved into a .cpp file and the build (with a unix linker - one that cannot handle circular library dependencies) should still succeed.<br class=""><br class=""><br class="">This last point is the most interesting - and I hope one that people generally find desirable, so it might not be immediately obvious why it may be contentious or difficult:<br class=""><br class="">LLVM violates this constraint by using inline functions in headers to avoid certain layering constraints that might otherwise cause the build to fail. A couple of major examples I've hit are:<br class=""><br class=""><a href="http://lists.llvm.org/pipermail/llvm-dev/2017-December/119494.html" style="color: purple; text-decoration: underline;" class="">TargetSelect.h<span class="Apple-converted-space"> </span></a>and similar: This one's especially tricky - the header is part of libSupport, but each function in here depends on a different subset of targets (creating a circular dependency) - to call the given function the programmer needs to choose the right dependencies to link to or the program will not link.<br class=""><a href="https://reviews.llvm.org/D41357" style="color: purple; text-decoration: underline;" class="">Clang Diagnostics</a><span class="Apple-converted-space"> </span>(work in progress): The diagnostics for each component are in their own component directories, but are then all included from libClangBasic, a library none of those components depends on. (so this isn't so much an inlining case as #include based circular dependency)<br class=""><br class=""><br class="">Generally I'd like to get buy-in that stricter layering is desirable, and that these few cases are at least sub-optimal, if accepted for now.<br class=""><br class="">Happy to go into more details about any of this, examples, etc, but I realize this is already a bit long.<br class="">- Dave<o:p class=""></o:p></div></div></div></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">LLVM Developers mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a></span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></span></div></blockquote></div><br class=""></body></html>