similar to: Make llvm-commits default cc on Phabricator

On 04/24/2020 03:24 AM, Sam McCall wrote: > clangd's experience using github issues to track bugs (in a separate repo) has been very positive, and I'm glad you're pushing on this! > > Part of this has been that our issue tracker has been scoped to our subproject only, which is a scope that the tool works well for (on the user and developer side). > As such I don't

+llvm-dev, so we get wider input :) Given how unfortunate reviews that are started without cc'ing the right list are (basically folks need to re-send the review from scratch), I support this idea. Ben, couldn't rL still be available for all projects? (and be the main project for LLVM). On Tue, Nov 21, 2017 at 5:18 PM Ben Hamilton via cfe-dev < cfe-dev at lists.llvm.org> wrote:

Hi Ben, (+llvm-dev since the email I'm replying to wasn't sent there) 2017-11-21 17:18 GMT+01:00 Ben Hamilton via cfe-dev <cfe-dev at lists.llvm.org> : > OK. I confirmed that Stephan's process to send out cross-repo diffs from > the monorepo is not affected by my proposal. > > I'm a bit late to the party, and I might just not have comprehended this correctly.

On Thu, Nov 23, 2017 at 12:58 AM Ben Hamilton <benhamilton at google.com> wrote: > Absolutely — I should have mentioned that we would keep the main rL > project and continue to use it. > Your original email said "Moving forward, only LLVM commits will be identified with the prefix rL (as in https://reviews.llvm.org/rL12345) — each project will get its own unique prefix, which

Forgot to mention: > Also, how would arcanist pick up two callsigns here? Wouldn't it just pick the from the closest surrounding .arcconfig? The review request will belong to a single repository, as you noticed (from the closest .arcconfig to where the arc command was invoked). However, when commits land, they will be imported under either one (rL for LLVM diffs) or two (rL + rC for e.g.

Hello, Is there a way for Phabricator to retain the patches as originally uploaded? When using the "Download Raw Diff" button, it seems Phabricator reformats the patch, loosing the parent commit along the way, so often patches don't apply. The following works, because I've got the latest checkout on master, and the patch was rebased recently: F:\llvm-project>curl

Times for lld compiled with LTO: Input File Reading: 1430 ms ( 3.3%) Code Layout: 486 ms ( 1.1%) PDB Emission (Cumulative): 41042 ms ( 94.6%) Add Objects: 33117 ms ( 76.4%) Type Merging: 25861 ms ( 59.6%) Symbol Merging: 7011 ms ( 16.2%) TPI Stream Layout: 996 ms ( 2.3%) Globals Stream Layout:

This could be ICF. There were lots of issues with ICF on ARM64, but they are not inherently ARM64-specific, they just come up there more often. See https://reviews.llvm.org/D56986 which fixes that. Easiest thing is always to profile or add /time to see what's slow. On Wed, Feb 27, 2019 at 6:30 AM Leonardo Santagada <santagada at gmail.com> wrote: > Anyone would know why lld takes

Yes, -Tllvm works. [cid:image002.jpg at 01D4CCF6.C440CFF0] From: Zachary Turner <zturner at google.com> Sent: Monday, February 25, 2019 10:36 AM To: Leonardo Santagada <santagada at gmail.com> Cc: Alexandre Ganea <alexandre.ganea at ubisoft.com>; Reid Kleckner <rnk at google.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Making LLD PDB

Can you please try using Ninja instead? cmake -G Ninja f:/svn/llvm -DCMAKE_BUILD_TYPE=Release -DLLVM_OPTIMIZED_TABLEGEN=true -DLLVM_EXTERNAL_LLD_SOURCE_DIR=f:/svn/lld -DLLVM_TOOL_LLD_BUILD=true -DLLVM_ENABLE_LLD=true -DCMAKE_C_COMPILER="C:/Program Files/LLVM/bin/clang-cl.exe" -DCMAKE_CXX_COMPILER="C:/Program Files/LLVM/bin/clang-cl.exe" -DCMAKE_LINKER="C:/Program

cc Paul / MyDeveloperDay De : llvm-dev <llvm-dev-bounces at lists.llvm.org> De la part de David Blaikie via llvm-dev Envoyé : April 8, 2020 10:21 PM À : Raphael “Teemperor” Isemann <teemperor at gmail.com>; Manuel Klimek <klimek at google.com> Cc : llvm-dev <llvm-dev at lists.llvm.org> Objet : Re: [llvm-dev] Outdated Phabricator version on reviews.llvm.org breaks Google

Sadly the patch on https://reviews.llvm.org/D55585 didn't apply on my clone of llvm at all :( It will take me quite some time to test this out. On Mon, Feb 25, 2019 at 5:08 PM Alexandre Ganea <alexandre.ganea at ubisoft.com> wrote: > > For enabling large memory pages, see this link: https://support.sisoftware.co.uk/knowledgebase.php?article=52 > > Meow hash isn't in the

Hi folks, phabricator maintenance is a topic that has been lying dormant for a while now. That subsequently creates a non-optimal user experience. For me personally, given that github provides a secure PR infrastructure, the additional effort required to keep Phab going is not an investment I'm personally willing to make. I understand that there are unique selling points for Phab in its UI

I think its a huge bug that it doesn't raise any errors or warnings about it. But I will open a ticket on cmake, they should be using clang-cl.exe and lld-link.exe if T="llvm" probably set host to 64 bit as well. On Mon, Feb 25, 2019 at 3:34 PM Zachary Turner <zturner at google.com> wrote: > > I don’t think changing the compiler or linker is supported with the vs

As for multithreaded ghashes: Even if the hashtable stores 32-bit indices to SeenHashes, you would still need to compare the ghashes for collisions: https://github.com/llvm/llvm-project/blob/master/llvm/include/llvm/ADT/DenseMap.h#L627 Finding the 32-bit index in the hashtable doesn’t necessarily mean it’s the right one. The following table shows the collision distribution when inserting (type)

That's good news. For having debug info, you could try adding /Z7 on the cmake cmd-line, such as -DCMAKE_CXX_FLAGS="/Z7". Or use the 'RelWithDebInfo' target instead of 'Release' and add -DCMAKE_CXX_FLAGS="/Ob2" (because that target uses /Ob1 as a default). Can you please send a patch on Phabricator if you fix the LLVM_ENABLE_PDB issue with Clang? The goal

How do you compile LLD? There's a big difference between when using MSVC vs Clang. The parallel ghash patch I was mentioning is almost 2x as fast when using Clang 7.0+ vs. MSVC 15.9+, I don't know exactly why. I also suggest you use the Release target. You should also grab this patch: https://reviews.llvm.org/D55056 - I had to revert it because it was causing issues with LLDB. But it

Thanks for the suggestion James, it reduces the commit by about ~900 MB (14,9 GB -> 14 GB). Unfortunately it does not solve the performance problem. The heap is global to the application and thread-safe, so every malloc/free locks it, which evidently doesn’t scale. We could manually create thread-local heaps, but I didn’t want to go there. Ultimately allocated blocks need to share ownership

Just my 2 cents here: we are working on enabling this as a part of bugzilla migration as PRs and issues are very tied inside GitHub. Stay tuned for updates! On Fri, Jun 19, 2020 at 3:45 PM Manuel Klimek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > -Chris' outdated email, +Chris' correct email :) > > On Fri, Jun 19, 2020 at 2:01 PM Manuel Klimek <klimek at

Hi, I’d just like to interject to say that building within Visual Studio isn’t really that bad. Running the lit tests is a bit painful because the LLVM build tools that are integrated with the build system don’t play nice with msbuild. Particularly, I’ve never been able to actually cancel an invocation of lit or tablegen via visual studio. That said, there is a huge upside to building with