similar to: [LLVMdev] Please document the layers

On Apr 8, 2013, at 2:55 PM, "Robinson, Paul" <Paul_Robinson at playstation.sony.com> wrote: I keep seeing "this is a layering violation" comments on the lists. > While there are a few llvm.org pages that mention layers in passing, > there is nothing (that I've found) actually specifying the layers. > Trying to infer the layering from the code is tedious and

Looking at build-procedure files for link-order hints is technically "written down" but not really human-friendly and not at all what I had in mind. ☺ I get that writing it down on a doc page will have the usual bit-rot problems, but if you want to tell developers (especially newer developers) "get the layering right" you really need to point to a place that says what the

On Wed, Jan 17, 2018 at 11:25 AM Robinson, Paul <paul.robinson at sony.com> wrote: > Looking at build-procedure files for link-order hints is technically > "written down" but not really human-friendly and not at all what I had in > mind. J > > I get that writing it down on a doc page will have the usual bit-rot > problems, but if you want to tell developers

So I'm poking around trying to improve the layering of LLVM (using an internal strict modular build as a motivation/tool to identify issues) & came across a layering violation in the OptBisect implementation. This feature is implemented in lib/IR, but includes several headers from include/llvm/Analysis - which would create a circular dependency if not for the fact that all the headers it

On Tue, Jan 16, 2018 at 10:15 AM Robinson, Paul <paul.robinson at sony.com> wrote: > I have found layering to be a particularly useful and beneficial model in > past large software projects. > > > > 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;

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

I have found layering to be a particularly useful and beneficial model in past large software projects. 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. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of

I wanted to go through and map out the layering of LLD's libraries today and found that it's essentially impossible. I think some serious cleanup is needed here. Let's start with the purely link-level dependencies encoded in the CMake build: Curently the Core library depends on the ReaderWriter/Native library, which links against the ReaderWriter library, which links against the Core

On Tue, Nov 28, 2017 at 11:23 AM, David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Alternatively we can really say this header is a textual header - it's > included generally only once in a whole program, the functions are called > only once, etc. Though that does seem a little unfortunate on principle but > not much practical problem with it, I think.

On Tue, Nov 28, 2017 at 11:27 AM Reid Kleckner <rnk at google.com> wrote: > On Tue, Nov 28, 2017 at 11:23 AM, David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Alternatively we can really say this header is a textual header - it's >> included generally only once in a whole program, the functions are called >> only once, etc. Though

On Tue, Jan 20, 2015 at 5:35 PM, Nick Kledzik <kledzik at apple.com> wrote: > On Jan 19, 2015, at 6:33 PM, Chandler Carruth <chandlerc at google.com> > wrote: > > > I wanted to go through and map out the layering of LLD's libraries today > and found that it's essentially impossible. I think some serious cleanup is > needed here. > > > >

I'm looking at fixing some layering violations in LLVM & came across a few in the CodeView handling, specifically: lib/MC/MCCodeView includes several llvm/DebugInfo/CodeView headers I guess MC could be made dependent on DebugInfoCodeView? But probably these things should be sunk into BinaryFormat as is the case for DWARF features used by MC? include/llvm/Object/COFF.h includes

On 01/16/2018 09:21 AM, David Blaikie via llvm-dev wrote: > Context: I've been looking at experimenting with using Modular Code > Generation (My talk at last year's LLVM dev meeting > https://www.youtube.com/watch?v=lYYxDXgbUZ0 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

My only alternate ideas are: a) To heck with this only a single target thing. b) Autogenerate the entire file and library support as part of the build and have the various functions "defined" in the appropriate libraries. I don't really think a) is feasible, and b) is a bit of a stretch too. :\ -eric On Mon, Dec 4, 2017 at 5:37 PM David Blaikie <dblaikie at gmail.com>

On Tue, Jan 16, 2018 at 11:35 AM Philip Reames <listmail at philipreames.com> wrote: > > > On 01/16/2018 09:21 AM, David Blaikie via llvm-dev wrote: > > Context: I've been looking at experimenting with using Modular Code > Generation (My talk at last year's LLVM dev meeting > https://www.youtube.com/watch?v=lYYxDXgbUZ0 is about the best reference > at the

Someone internally's been dabbling with turning on some of Google's build system's stricter header checking modes - and they caught these (you can check the internal code review 184305506 for the original where I'm pulling things out from). & yeah, fair question about the modules builds - I don't fully understand what they catch and don't catch. I suspect it's a

On Wed, Jan 17, 2018 at 1:27 PM Chandler Carruth <chandlerc at gmail.com> wrote: > On Tue, Jan 16, 2018 at 11:35 AM Philip Reames <listmail at philipreames.com> > wrote: > >> >> >> On 01/16/2018 09:21 AM, David Blaikie via llvm-dev wrote: >> >> Context: I've been looking at experimenting with using Modular Code >> Generation (My talk at

Could you guys clarify one thing for me? It sounds like the idea is that the current model of configuring the selection of targets would go away, to be replaced by an all-or-native-only switch. Sometimes I like to configure X86+ARM because that reduces rebuild time and still gets me the vast majority of debug-info tests. Or maybe you're using "all" as a shorthand for "all

Context: I've been looking at experimenting with using Modular Code Generation (My talk at last year's LLVM dev meeting https://www.youtube.com/watch?v=lYYxDXgbUZ0 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

Intuitively I'd think MC and DebugInfo should be independent. MC is a producer, DebugInfo is a consumer. What's common is the definition of the structures they operate on, which doesn't properly belong to either one. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of David Blaikie via llvm-dev Sent: Wednesday, March 21, 2018 11:52 AM To: Zachary Turner