<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jan 16, 2018 at 10:43 AM Matthias Braun <<a href="mailto:mbraun@apple.com">mbraun@apple.com</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;line-break:after-white-space"><div>I would describe it from this angle: LLVM is layered just fine. </div></div></blockquote><div><br>Yeah, in most cases/in general I agree.<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;line-break:after-white-space"><div>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.</div></div></blockquote><div><br>Actually even more than that - on unix, linkers don't resolve circular dependencies (they start with a list of unresolved symbols and walk the link line left to right - resolving any symbols they can iteratively while looking at one library, then moving on to the next - never going back to an earlier library to resolve a later dependency), this enforces quite a lot of the layering constraints we usually think about. Google's build system enforces things a bit more strictly, I think (even without modular codegen) & that's generally been a good/accepted thing - though I don't have any precise examples to point to, unfortunately.<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;line-break:after-white-space"><div> 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></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></blockquote><div><br>Yep - my goal is just to enshrine that understanding in documentation so it's a bit more of an explicit/clear goal going forward.<br><br>I may be able to fix some of the existing violations - but mostly wanting to sure up things for future changes.<br><br>- Dave<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;line-break:after-white-space"><div><br></div><div>- Matthias</div><div><br></div><div><blockquote type="cite"></blockquote></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><div>On Jan 16, 2018, at 10:15 AM, Robinson, Paul via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="m_8371689140735323727Apple-interchange-newline"></blockquote></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><div><div class="m_8371689140735323727WordSection1" 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"><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I have found layering to be a particularly useful and beneficial model in past large software projects.<u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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.<u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">--paulr<u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><a name="m_8371689140735323727__MailEndCompose"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></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"><div><div style="border-style:solid none none;border-top-width:1pt;border-top-color:rgb(181,196,223);padding:3pt 0in 0in"><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"><span class="m_8371689140735323727Apple-converted-space"> </span>llvm-dev [<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">mailto:llvm-dev-bounces@lists.llvm.org</a>]<span class="m_8371689140735323727Apple-converted-space"> </span><b>On Behalf Of<span class="m_8371689140735323727Apple-converted-space"> </span></b>David Blaikie via llvm-dev<br><b>Sent:</b><span class="m_8371689140735323727Apple-converted-space"> </span>Tuesday, January 16, 2018 9:22 AM<br><b>To:</b><span class="m_8371689140735323727Apple-converted-space"> </span>llvm-dev; Richard Smith; Chandler Carruth; Reid Kleckner<br><b>Subject:</b><span class="m_8371689140735323727Apple-converted-space"> </span>[llvm-dev] Layering Requirements in the LLVM Coding Style Guide<u></u><u></u></span></div></div></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><u></u> <u></u></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif">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" target="_blank">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><br>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><br><br>Currently the<span class="m_8371689140735323727Apple-converted-space"> </span><a href="https://llvm.org/docs/CodingStandards.html" style="color:purple;text-decoration:underline" target="_blank">LLVM Coding Standards</a> doesn't say much/anything about layering.<span class="m_8371689140735323727Apple-converted-space"> </span><a href="https://llvm.org/docs/CodingStandards.html#a-public-header-file-is-a-module" style="color:purple;text-decoration:underline" target="_blank">'A Public Header File<span class="m_8371689140735323727Apple-converted-space"> </span><b>is</b><span class="m_8371689140735323727Apple-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><br>I propose making this wording a bit more explicit, including:<br><br>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><br>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><br>And the actual layering issue:<br>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><br><br>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><br>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><br><a href="http://lists.llvm.org/pipermail/llvm-dev/2017-December/119494.html" style="color:purple;text-decoration:underline" target="_blank">TargetSelect.h<span class="m_8371689140735323727Apple-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><a href="https://reviews.llvm.org/D41357" style="color:purple;text-decoration:underline" target="_blank">Clang Diagnostics</a><span class="m_8371689140735323727Apple-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><br><br>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><br>Happy to go into more details about any of this, examples, etc, but I realize this is already a bit long.<br>- Dave<u></u><u></u></div></div></div></div></div></blockquote></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><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;float:none;display:inline!important">_______________________________________________</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"><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;float:none;display:inline!important">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"><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;float:none;display:inline!important"><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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"><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;float:none;display:inline!important"><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></span></div></blockquote></div><br></div></blockquote></div></div>