similar to: Who wants faster LLVM/Clang builds?

It's also likely that a lot of '#include "foo.h"' can be replaced with 'class foo;' Especially in the transitive inclusion case, instead of removing the #include entirely. On Wed, Dec 6, 2017 at 8:38 AM, Chris Lattner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I, for one, want faster builds. > > Beyond that though, this seems like obvious

> To find which header files could be removed it scanned the file for "#include" lines and tried to remove them one by one (checking if the file still compiles after the removal). When there were no more include lines to remove, we verified the change with ninja+ninja check. It looks like this makes us rely heavily on transitive header includes -- is that right? Specifically what I

Hey all, IWYU maintainer here. I wanted to make a small observation. Surprisingly, IWYU will most often *add* includes to a reasonably well-factored codebase, and this ties into Chris' comment: > Beyond that though, this seems like obvious > goodness to reduce coupling in the codebase. Just blindly removing includes will probably increase coupling, not reduce it, because it optimizes

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 >

Hi, I tweaked my scripts to avoid removing includes when it doesn't give any significant benefits, which made the patches significantly smaller. This time the patches should not try to remove includes of header files, which are transitively included from other included header files. The gains mostly remained the same (plus/minus noise), the tables are in the end of the email. I also included

> On Dec 6, 2017, at 9:00 AM, mats petersson via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > In my experience, a lot of time is spent on optimizing the code (assuming it's not a "-O0" build). The numbers were actually for the debug build (-O0 -g), so for Release build they would be different (presumably lower). > Also redundant includes are largely fixed by

- We do indeed have a lot of unnecessary includes around in llvm (or pretty much any other C++ project for that matter). - I want faster builds. - The only way to reliably fight this is indeed automatic tools. - Having the right amount of includes also has documentation value and ideally let's you understand the structure of your project. - However relying on transitive includes works contrary

[Sorry about the crosspost. Since this is a clang build question but the build is invoked from the top-level LLVM directory I'm not sure where the question should go.] I've got a clang build against libstdc++ on Linux but I would really like one built against libc++/libc++abi. In other words I'd like to rebuild clang/llvm with clang using libc++ and libc++abi on Linux. I looked at

If your cut-n-paste is accurate, you seem to be missing a closing quote for CMAKE_CXX_LINK_FLAGS. hth... don On Jul 8, 2015 2:22 AM, "David A. Greene" <greened at obbligato.org> wrote: > greened at obbligato.org (David A. Greene) writes: > > > I looked at the instructions on the libc++ page and for Linux it > > recommends building with -stdlib=libc++ -lc++abi.

Could you direct me to a newbie-friendly instructions for installing the latest versions of R and RStudio on Linux Mint 21.2? I followed instructions I could find, but no luck with managing to get RStudio (tho I did install R). System: Kernel: 6.2.0-39-generic x86_64 bits: 64 compiler: N/A Desktop: MATE 1.26.0 Distro: Linux Mint 21.2 Victoria base: Ubuntu 22.04 jammy I was able to install

On Sun, Oct 23, 2011 at 10:34 PM, James Molloy wrote: > Hi, > > I haven't seen those errors. Clang and LLVM both build with no warnings on the 3 versions of GCC I test with. MSVC reports loads of warnings however. > $ make happiness ... Updated to revision 142790. ... make[4]: Entering directory `/home/ecsardu/LLVM/build-tcclab1/tools/clang/tools/libclang' llvm[4]: Compiling

Hello everyone! I've found weird lines of code in tools/libclang/CIndex.cpp file in clang sources. Function clang_tokenize holds the following lines: *Tokens = (CXToken *)malloc(sizeof(CXToken) * CXTokens.size()); memmove(*Tokens, CXTokens.data(), sizeof(CXToken) * CXTokens.size()); Since malloc function can return null pointer and there are no checks for this case, memmove invocation

Hi Michael, On Thu, Dec 7, 2017 at 3:16 AM, Michael Zolotukhin <mzolotukhin at apple.com> wrote: > > Nice to IWYU developers here:) I wonder how hard it would be to run IWYU on > LLVM/Clang (or, if it’s supposed to work, I wonder what I did wrong). There are known problems with running IWYU over LLVM/Clang -- Zachary Turner made an attempt a while back to get it up and running.

Hi, I haven't seen those errors. Clang and LLVM both build with no warnings on the 3 versions of GCC I test with. MSVC reports loads of warnings however. Cheers, James ________________________________________ From: Csaba Raduly [rcsaba at gmail.com] Sent: 23 October 2011 18:44 To: James Molloy Cc: Paul Berube; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] build warnings On Sat, Oct 22,

On Sat, Oct 22, 2011 at 12:24 AM, James Molloy wrote: > Hi Paul, > > That should be easy enough, because the LLVM build has no warnings in it! > > Some of us build with -Werror, and even with those of us that don't warnings are not tolerated. You're already seeing all the warnings that are coming out of the build :) So, all the "variable might be used

Hi everyone, I wanted to assign a new pragma for loops in clang. Let's call it "#pragma XXX" which can be applied to any loop in the entire loop hierarchy. I added the support for my pragma by following the same steps as were being used in the default implementation of "unroll" pragma. But now, when I compile any program using clang to llvm IR it attaches the pragma

On Mon, Dec 11, 2017 at 3:37 PM, Mikhail Zolotukhin via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Hi Kim, > > On Dec 10, 2017, at 7:39 AM, Kim Gräsman <kim.grasman at gmail.com> wrote: > > Hi Michael, > > On Thu, Dec 7, 2017 at 3:16 AM, Michael Zolotukhin > <mzolotukhin at apple.com> wrote: > > > Nice to IWYU developers here:) I wonder how

Allow changes in static matrices to not break/disrupt code in OpusProjection* APIs. + Minor bug/typo fixes. This patch depends on [PATCH] "Ensure mapping matrix size is always valid." Cheers, Drew -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20171205/3fbd2af1/attachment.html> -------------- next

I'm a little late to the party, but one observation that I haven't seen mentioned is that simply removing #includes and testing that the program compiles is not guaranteed to be a correct transformation. Imagine, for example, that a header file provides an overload of a function that is a better match than one found elsewhere. It will compile either way, but without the #include, you

Hi, I'm try to build llvm on my PC but it failed. I'm using following command, $ cmake -G "Ninja" ../llvm -DCMAKE_INSTALL_PREFIX=prefix=$INSTALL_PATH -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=On $ ninja-build -j 2 I have skipped libcxx and libcxxabi package. It shows below error, 00:04:23 [3261/3430] Building CXX object