similar to: Layering Requirements in the LLVM Coding Style Guide

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

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

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

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

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

On Tue, Jan 16, 2018 at 10:43 AM Matthias Braun <mbraun at apple.com> wrote: > I would describe it from this angle: LLVM is layered just fine. > Yeah, in most cases/in general I agree. > 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. > Actually even more than that - on unix,

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;

So, I'm setting about trying to fix the layering of TargetSelect.h (& TargetRegistry.h, but haven't really got to its issues yet). The issues can be demonstrated fairly plainly by moving any/all of TargetSelect.h's functions out of line. Pretty much all programs in LLVM fail to link because libSupport doesn't actually depend on all the targets, quite the opposite in fact. So,

So I decided to bundle up the small amount of work I've done on generating source-level debugging info into a DebugInfoBuilder class like I described earlier. I went and added a new file to the "Support" directory (in include and lib). However, when I try to compile it, it complains of a circular dependency error between libCore and libSupport: find-cycles.pl: Circular

HyperQuantum wrote: > I'm not a LLVM developer, but I'll give it a try... > > On Wed, Jun 4, 2008 at 9:12 AM, Talin <viridia at gmail.com> wrote: > > >> I went and added a new file to the "Support" >> directory (in include and lib). However, when I try to compile it, it >> complains of a circular dependency error between libCore and

I'm not a LLVM developer, but I'll give it a try... On Wed, Jun 4, 2008 at 9:12 AM, Talin <viridia at gmail.com> wrote: > I went and added a new file to the "Support" > directory (in include and lib). However, when I try to compile it, it > complains of a circular dependency error between libCore and libSupport: > > find-cycles.pl: Circular dependency

CodeGen, since it depends on MachineModuleInfo. On 2008-06-05, at 04:06, Talin wrote: > HyperQuantum wrote: >> I'm not a LLVM developer, but I'll give it a try... >> >> On Wed, Jun 4, 2008 at 9:12 AM, Talin <viridia at gmail.com> wrote: >> >> >>> I went and added a new file to the "Support" >>> directory (in include and

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.

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

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, 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

2017-05-29 9:25 GMT-07:00 Zachary Turner <zturner at google.com>: > On Sun, May 28, 2017 at 8:54 PM Mehdi AMINI via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < >> llvm-dev at lists.llvm.org>: >> >>> Changing a header file somewhere and having to spend 10 minutes waiting

According to the LLVM coding standards, Immediately after the header file comment <http://llvm.org/docs/CodingStandards.html#header-file-comment> (and include guards if working on a header file), the minimal list of #includes <http://llvm.org/docs/CodingStandards.html#minimal-list-of-includes>required by the file should be listed. We prefer these #includes to be listed in this order:

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

Generally it is safer to include ISO headers first (using the ‘#include <...>’ form) so as to minimise the possibility that a later user declaration or macro definition interferes with the correctness of the Standard libraries. It also tends to make pre-compiled header implementations faster and more shareable across a larger set of files. I would like to suggest revising the LLVM