similar to: [LLVMdev] Phabricator loves Amara

Hi, At the last EuroLLVM, I gave a lightning talk about code review statistics on Phabricator reviews and what we could derive from that to try and reduce waiting-for-review bottlenecks. (see https://llvm.org/devmtg/2018-04/talks.html#Lightning_2). One of the items I pointed to is a script we've been using internally for a little while to try and match open Phabricator reviews to people who

On Wed, Jun 25, 2014 at 3:30 PM, John Criswell <criswell at illinois.edu> wrote: > On 6/25/14, 5:15 PM, Vadim Chugunov wrote: > > In a recent review via Phabricator, I was receiving bounce notifications for > mail being sent to llvm-commits because of "Too many recipients to the > message", even though I am a subscriber. I wonder how common is that. > > >

I just saw this, and I have to say -- thanks, Kristof! Do you know if this is something that could be automated in Phabricator, instead of something that people run on their own? Or is the intent of this to be something that ran regularly (say, weekly or daily) that would email people (or the list) that could be doing the reviews for some of the open patches? On Sat, Apr 28, 2018 at 1:01 AM,

I have seen the "Too many recipients to the message" several times. A limit of 10 includes the patch author and the list leaving just 8 subscribers/reviewers is way too low. Given that these e-mails can be sent only by a Phab. user I'm not sure that spam is a problem at all: A potential spammer would first have to subscribe to Phab. then create a proper diff,... far easier just to

On 9 February 2017 at 17:31, Amara Emerson <amara.emerson at gmail.com> wrote: > Ping. Does anyone else have thoughts on this? Hi Amara, It seems the people who replied in this thread are mostly in sync with the proposal, why don't you push a review in phab, and let's take this to the next level? cheers, --renato

Amara, first, thank you for answering. but I found expandPsuedo instructions actually happens before post-RA, like the following code showing: your approach is a little hacky, right? : ) // Expand pseudo instructions before second scheduling pass. addPass(&ExpandPostRAPseudosID); printAndVerify("After ExpandPostRAPseudos"); // Run pre-sched2 passes. if (addPreSched2())

I think this after a second. I got your point. I can define a pseudo instruction for an instr-pair and expand it after post-RA-sched. as you said, in preEmitPass. The original intrinsic can also be kept. I just convert the intrinsic to pseudo instruction in TargetLower. Thank you for your enlightening suggestion! thanks, --lx On Sat, Nov 23, 2013 at 8:37 PM, Amara Emerson <amara.emerson at

What I meant was to write your own expansion pass and run it after the scheduler passes, e.g. in the pre-emit stage. > if (addPreEmitPass()) printAndVerify("After PreEmit passes") Though if it's too hacky for you then fair enough. Amara On 23 November 2013 03:17, Liu Xin <navy.xliu at gmail.com> wrote: > Amara, > > first, thank you for answering. but I found

Yes, SVE can vectorize early exit loops by using speculative (first-faulting) loads, which essentially give a predicate of the lanes loaded successfully. For uncounted loops with these special loads, the loop predicate tests can be done using a 'ptest' instruction, checking if the last element is active. Amara On 3 February 2017 at 10:15, Simon Pilgrim <llvm-dev at redking.me.uk>

Parsing the arch string is a bit icky, but I don't really have too much of a problem with it - and it's better than -mcpu so... -eric On Tue Jan 07 2014 at 9:23:43 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 7 January 2014 17:05, Amara Emerson <amara.emerson at arm.com> wrote: > > We plan on implementing this interface for AArch64 Clang in future, and

I am not using llvm tools, but sources and directly calling into relevant LLVM classes and methods. Thanks, Daman On 23/06/14 4:11 pm, "Amara Emerson" <amara.emerson at gmail.com> wrote: >Hi Damanjit, > >I assume you're trying to use the tools like llvm-mc, in which case >you can use the -mattr=+vfpv3 flag to enable it. This applies to other >subtarget

Dear LLVM / Clang community, we'd like to open the use of Phabricator as an optional tool for doing code reviews to a wider audience. Please feel free to start your code reviews by following the documentation at http://llvm.org/docs/Phabricator.html. Note that e-mail is still the reference medium for code reviews. Please let me know about any problems with Phabricator or the documentation

I knew I'd regret leaving that option in for the MIPS port back in 99. Basically this is the only acceptable way for mcpu to exist, but should never have been added to the GCC aarch64 port at all since there's no compatibility with existing build systems to worry about. I would still like you to show this mythical piece of software that needs this compatibility. -eric On Jan 8, 2014 3:06

On 12 October 2013 23:00, Amara Emerson <amara.emerson at gmail.com> wrote: > Hi Jan, > > For Cortex-M0, you should probably use the armv6m string in the target > triple. For M3 and M4 you need to use the thumbv7m arch string, -mthumb > won't be necessary. > Yes, but I agree with Jim that a bug must be filled. Jan, would you mind filling a bug?

FYI all: the patch to enable it is available to review here: https://reviews.llvm.org/D41362 Thanks, Amara > On Dec 18, 2017, at 5:44 PM, Amara Emerson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Ok. We’ll look at what we can do to further stress test it in the next two months, additional suggestions from the community is welcome. Patch should be incoming to enable it

Hi Amara, Thanks for your suggestions. I have made the changes you suggested and added a new test to check that we print an error when parsing a non-ldr mnemonic with an operand containing `=`. The updated patch is attached. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation > -----Original Message----- > From: Amara Emerson

Hi Manuel, It's been brought to my attention that my usage of the Phabricator Audit tool to track which commits have been reviewed is causing a large number of (almost) empty emails to be sent to the commit authors and anyone else added to the audit as a reviewer. Presumably there are some state change emails that we haven't blocked yet (e.g. the 'Accept commit' and 'Resign

I’ve put up a patch here: https://reviews.llvm.org/D79769 <https://reviews.llvm.org/D79769> that adds a unified pipeline that targets can opt-into. It has some similarities with forcing fallbacks, but uses a different mechanism to do so to preserve the abort behavior. It therefore requires that every GISel pass needs to explicitly check whether the GISel selector is being requested rather

Unless there are still open issues with your patch, or our internal bots point to problems, I think time has come to flip the switch. Thanks Gerolf > On Dec 18, 2017, at 11:14 AM, Amara Emerson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > FYI all: the patch to enable it is available to review here: https://reviews.llvm.org/D41362 <https://reviews.llvm.org/D41362>

Looks like there are a lot of opinions where memcpy expansion/inlining needs to happen: (late) IR, or if it is a backend problem, see also for example https://reviews.llvm.org/D35035. Complicating factor here is that efficient memcpy lowering is crucial for performance and code-size (and they occur a lot). Either way, I agree that the TLI hooks are not SelectionDAG specific, they can be used in