similar to: Should we split llvm Support and ADT?

It would be better, because a debug tablegen is slower than an optimized tablegen, but it's still slow and it doesn't address the problem that tablegen runs *at all* when it doesn't really need to. I think if tablegen wasn't running all the time we could incremental builds down from 15 minutes (and that's on my really powerful machine) to under 5, which seemed like a big

I thought we already did write tablegen output to temporary files like X86GenAsmWriter1.inc.tmp first and then diffed them with the real .inc file and conditionally copied. ~Craig On Sat, May 27, 2017 at 11:02 AM, David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Fri, May 26, 2017 at 8:06 PM Zachary Turner via llvm-dev < > llvm-dev at

It's that TableGen depends on Support, so if you change one file in support, support gets recompiled into a new static archive, which triggers a rerun of tablegen on all the tablegen inputs, which is extremely slow. On Fri, May 26, 2017 at 5:56 PM Hal Finkel <hfinkel at anl.gov> wrote: > > > On 05/26/2017 07:47 PM, Zachary Turner via llvm-dev wrote: > > Changing a header

In my experience the buildsystem works fine in combination with tablegen (at least this aspect of it). The real problem here is that tablegen is just slow. Some of the X86 tables take indeed Last time I looked at it tablegen had still room to optimize the way it resolves class hierarchies and the variables within which it did basically one at a time, so it needed to traverse the hierarchies

> On May 30, 2017, at 12:05 PM, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Let me try starting over without mentioning Tablegen :) Aw, but i had a list of issues, such as: - tablegen doesn’t generate .d files - CMake is set up with far reaching deps on .td files, so changing Options.td rebuilds the backends, and adding an ARM intrinsic rebuilds X86 or vice

On Mon, May 29, 2017 at 9:25 AM Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > 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

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 > for a build leads to a lot of wasted developer time. > > The real culprit here is tablegen. Can we split support and ADT into two > - the parts that tablegen depends on and the parts that it doesn't? >

> On May 30, 2017, at 3:49 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On May 30, 2017, at 12:05 PM, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Let me try starting over without mentioning Tablegen :) > Aw, but i had a list of issues, such as: > -

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

> On Jun 23, 2018, at 10:14, Chris Lattner <clattner at nondot.org> wrote: > > > >> On Jun 23, 2018, at 9:11 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com <mailto:dexonsmith at apple.com>> wrote: >> >>> >>> I think we might be better off just reducing the pre-allocation size of most of our SmallVectors across LLVM and Clang.

When compiling trunk using gcc 4.1.2 on linux/ppc64, I now see a warning that I don't remember seeing previously: llvm[2]: Compiling InlineSpiller.cpp for Release+Asserts build /src/llvm-trunk-dev/include/llvm/ADT/PointerIntPair.h: In member function ‘const PointerTy* llvm::PointerIntPair<PointerTy, IntBits, IntType, PtrTraits>::getAddrOfPointer() const [with PointerTy = void*, unsigned

tl;dr: I think we have too many different set classes. They have incompatible APIs and surprising behavior. I think we can reduce their number substantially. Dear all, The following is a subset of the set classes we have in ADT: * DenseSet * SmallDenseSet (https://reviews.llvm.org/D25628) * SetVector * SmallSetVector * SmallSet * SmallPtrSet * StringSet * FoldingSet *

I just switched gcc from 4.6.2 to 4.7.1 and see the massive amount of warnings, see few examples below. They mostly didn't exist with gcc-4.6.2. rev.159224 Yuri /usr/home/yuri/llvm-2012-06/latest-unpatched/llvm-fix/include/llvm/ADT/PointerUnion.h:56:10: warning: enumeral mismatch in conditional expression:

I was looking at the SymbolTable code in LLD COFF and ELF recently, and I’m confused by the use of CachedHashStringRef. From what I understand, a CachedHashStringRef combines a StringRef with a computed hash. There’s no caching going on in the CachedHashStringRef itself; that is, if you construct CachedHashStringRef("foo"), and then construct a second

Hi, I'm trying to build llvm (git monorepo) on Ubuntu 18.04 with EXPENSIVE_CHECKS enabled and running into various errors compiling SourceMgr.cpp, depending on which host compiler I use. For example with GCC: $ CC=gcc-8 CXX=g++-8 cmake -GNinja -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON ~/git/llvm-project/llvm/ && ninja ... [89/2690] Building CXX object

Hmm. What about the errors I quoted from using clang-7 (starting about a third of the way down my email, sorry if they got kinda lost in all the noise)? Thanks, Jay. On Tue, 3 Sep 2019 at 20:00, David Blaikie <dblaikie at gmail.com> wrote: > > Looks to me like a bug in GCC's constexpr+_GLIBCXX_CONCEPT_CHECKS support. Small test case: > > $ g++-8 test.cpp -std=c++2a

I just ran into this today. Do we need to update our requirements on libstdc++ version? Jay, did you figure out a way around this? On Wed, Sep 4, 2019 at 5:29 AM David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > It's a bug in libstdc++ - so if you have clang using libstdc++ (which it will by default, I think) then it's the same thing. You could try with

Hi Oliver, There would be no problem if both the Map and the Vector indeed contained (Key,Value) pairs. To save space, Map entries do not contain Value but instead an unsigned index into the Vector: /// The values are kept in a std::vector and the /// mapping is done with DenseMap from Keys to indexes in that vector. After an element is erased from the Vector all indices greater than the

> On 2014-Jul-15, at 10:05, David Blaikie <dblaikie at gmail.com> wrote: > > On Tue, Jul 15, 2014 at 9:43 AM, Duncan P. N. Exon Smith > <dexonsmith at apple.com> wrote: >> >>> On 2014-Jul-15, at 09:38, David Blaikie <dblaikie at gmail.com> wrote: >>> >>> On Tue, Jul 15, 2014 at 9:31 AM, Duncan P. N. Exon Smith >>>

> On 2014-Jul-15, at 08:29, David Blaikie <dblaikie at gmail.com> wrote: > > Sounds pretty clearly buggy, and against the original design of the > ADT (as pointed out by the documentation quotation). When was erase > functionality added to MapVector? Can/should it be removed (and the > use case changed to use some other container) > > Making erase linear time