similar to: LLVM coding standards and order of includes

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

On Sun, Feb 28, 2010 at 9:07 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Sun, Feb 28, 2010 at 1:02 PM, Russell Wallace > <russell.wallace at gmail.com> wrote: >> What's the largest integer such that something like 'return ((a * b) / >> c) >> d' works correctly on all major platforms? > > Twice the size of a pointer, i.e. 64 bits on

A quick coding standards question. The current coding standards doc has helpful guidance on Doxygen comments and the like: https://llvm.org/docs/CodingStandards.html#source-code-formatting One aspect which isn't explicit is the policy on duplicating code comments for subclasses. To modify an example from that doc: """ // In Something.h: /// An abstraction for some complicated

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

Hi Al, > It's good that llvm/lib builds with exceptions and RTTI disabled as it > supports doing optimization and codegen on very constrained platforms. > Judging by REQUIRES_EH in makefiles, only a few bits like TableGen, llvm-ar > and llvm-ranlib need them, and I doubt these would need to run on a target. > It's unlikely exceptions would get in in a random patch, because

> On Jan 9, 2017, at 10:29 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 9 January 2017 at 18:20, Reid Kleckner <rnk at google.com> wrote: >> I object to the first. If you need a new type name, use a typedef. It's time >> honored and everyone, including C programmers, will know what you're doing. >> I don't understand

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

Hi, It's good that llvm/lib builds with exceptions and RTTI disabled as it supports doing optimization and codegen on very constrained platforms. Judging by REQUIRES_EH in makefiles, only a few bits like TableGen, llvm-ar and llvm-ranlib need them, and I doubt these would need to run on a target. It's unlikely exceptions would get in in a random patch, because it would have to change the

Hi Kostya, One unexpected piece of fallout in your recent attributes change (r148553) was that it introduced a bunch of static constructors into .o files that #include Attributes.h, due to stuff like this: const Attributes None (0); ///< No attributes have been set const Attributes ZExt (1<<0); ///< Zero extended before/after call const Attributes SExt

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

In that case, RTTI and exception should also be disabled from CMake generated projects right? Currently they are enabled all over my MSVC projects. On Thu, Oct 14, 2010 at 3:57 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Al, > >> It's good that llvm/lib builds with exceptions and RTTI disabled as it >> supports doing optimization and codegen on very constrained

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

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 Jan 9, 2017, at 12:47 PM, Renato Golin <renato.golin at linaro.org> wrote: > > On 9 January 2017 at 19:04, Mehdi Amini <mehdi.amini at apple.com> wrote: >> This is not correct according to the number of “should” and the imperative tone for many aspects of http://llvm.org/docs/CodingStandards.html#source-code-formatting > > You mistake the tone of the

I’d like to discuss revising the LLVM coding conventions to change the naming of variables to start with a lowercase letter. This should not be a discussion on the pain of such a transition, or how to get from here to there, but rather, if there is a better place to be. My arguments for the change are: 1. No other popular C++ coding style uses capitalized variable names. For instance here

I see the problem. Let me try to come up with a solution that does not involve constructors but also does not sacrifice type safety. On Tue, Feb 7, 2012 at 12:01 PM, Chris Lattner <clattner at apple.com> wrote: > Hi Kostya, > > One unexpected piece of fallout in your recent attributes change (r148553) > was that it introduced a bunch of static constructors into .o files that

2017-12-09 12:54 GMT-08:00 Chris Lattner via llvm-dev < llvm-dev at lists.llvm.org>: > > > On Dec 8, 2017, at 5:01 PM, Mikhail Zolotukhin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hi, > > I tweaked my scripts to avoid removing includes when it doesn't give any > significant benefits, which made the patches significantly smaller. This >

Siddharth, I'm not sure what coding standards you refer to when you say "some C++ coding standard". This question is answered in the LLVM Coding Standards document here: https://www.llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions <https://www.llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions> As such LLVM's coding standards prohibit the

Hi everyone, I have a code style question: should full test programs (.c,.cpp files) use the documented CamelCase from http://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly or instead use lower_with_underscores as I've been told the .ll lit test files should use? I see both in existing files, and in particular for projects/compiler-rt I cannot