similar to: [Analysis] Introduce a new InstructionCost class

It might also make sense to have functions that return costs for vector ops return some sort of `LinearPolyBase` with `ScalarTy` being `InstructionCost`. From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Vineet Kumar via llvm-dev Sent: Monday, November 16, 2020 11:24 PM To: David Sherwood <David.Sherwood at arm.com>; llvm-dev at lists.llvm.org Subject: [EXT] Re:

Makes sense. I personally greatly prefer having a type rather than a `static constexpr int CostUnfathomable = 10000`. I think the type should have arithmetic operators defined such that an "invalid cost" on either side results in an invalid cost (similar to how NaN infects floats), and an implicit conversion that constructs a valid cost. Then I could just do: ``` Cost c = 7; // c is a

Hi Chris, Thanks for the reply. My email was really to just ask if people were ok with the idea in principle and I kind of deliberately avoided getting into too many details at this point. If people are happy with the idea in principle I can push a patch up soon that shows what such a class could like so that people can comment on it? Regards, David Sherwood. From: Chris Tetreault <ctetreau

Hi all, It's been a while since we've given an update on scalable vector support in LLVM. Over the last 12 months a lot of work has been done to make LLVM cope with scalable vectors. This effort is now starting to bear fruit with LLVM gaining more capabilities, including an intrinsics interface for AArch64 SVE/SVE2, LLVM IR Codegen for scalable vectors, and several loop-vectorization

You're being quite vague about what the extra state is. Is this because you haven't yet settled on what it should be, or do you actually intend to let it be a template parameter: template <typename T> struct Cost { unsigned Val; T State; } Thanks, Christopher Tetreault From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of David Sherwood via llvm-dev Sent:

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,

On 6/22/20 2:34 AM, Manuel Klimek via llvm-dev wrote: > On Sat, Jun 20, 2020 at 1:45 AM Zachary Turner via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > There’s also some feature regressions in GH vs Phab. > > You *must* initiate a review via a pull request, and pull request > by definition compares your working

On Fri, 19 Jun 2020, 18:55 Hubert Tong, <hubert.reinterpretcast at gmail.com> wrote: > On Fri, Jun 19, 2020 at 12:32 PM Anton Korobeynikov via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 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 Thu, Jun 25, 2020 at 1:12 AM Manuel Klimek <klimek at google.com> wrote: > Mehdi, Fangrui: are you willing to take on maintenance? > Sure, let's work out a transition plan offline! > > Otherwise, Shoaib, the cost is currently: > ~$300-350 / mo for sendgrid (300-350k emails / month) > ~$2k / mo for cloud (we currently run on 1 machine O.O, plus storage & >

-1 from me as well. GitHub UI feels extremely sluggish with large projects, forks feel like needless hurdles to jump over, especially for small patches - having to fork the entire monorepo, just to do a GitHub PR would be extremely cumbersome. Just recently I submitted a very tiny PR for PcapPlusPlus on GitHub which involved: 1). Forking the repository 2). Cloning the fork 3). Applying the patch

Hi all, This is a request for comment on a series of patches which introduce a new way of writing algorithms that are generic over different types of CFG. What is this? ============= This series of patches introduces a set of classes and templates for: 1. Working on basic blocks and values generically, in particular with the same algorithm implementation on both LLVM IR and MachineIR (in SSA

The proposed addition to ProgrammersManuel.rst is below the break... This is essentially trying to explain the emerging design techniques being used in LLVM these days somewhere more accessible than the comments on a particular piece of infrastructure. It covers the "concepts-based polymorphism" that caused some confusion during initial reviews of the new pass manager as well as the

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

I think that it's really important that we try to strike some balance here. Based on my experience, this thread, and offline conversations, two things seem clear to me: 1. Overall, Phabricator is a superior tool for managing code reviews and some related processes (although GitHub's tools certainly have some benefits, and both are getting better over time). 2. Not accepting GitHub PRs

On Wed, Oct 17, 2012 at 8:25 PM, Sean Silva <silvas at purdue.edu> wrote: > You might want to mention other functionality, like Herald, which I > think fills a need that a lot of developers have. > > Well, I guess since this message is on the list, I can just say: > Phabricator's "Herald" tool lets you (among other things) set up > actions to happen in

I can’t really provide a doc, but i can describe what I believe to be the biggest problem. In a GH PR, comments are associated with commit hashes. If a commit hash ceases to exist, so do all comments associated with it. The comments are quite literally destroyed and irretrievable. What this means for LLVM is that everyone will have to completely stop using history rewriting operations. No

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

On Fri, Jun 19, 2020 at 1:15 PM Keith Smiley <keithbsmiley at gmail.com> wrote: > FWIW GitHub's code review tools have improved significantly in the past > few years. At this point with reviews and manual control over resolving / > unresolving comments I think many previous complaints I've seen about > GitHub vs Phabricator have been alleviated. > To be clear: this

On Mon, Jun 22, 2020 at 2:33 AM Manuel Klimek <klimek at google.com> wrote: > On Fri, Jun 19, 2020 at 10:04 PM Mehdi AMINI via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> >> >> On Fri, Jun 19, 2020 at 9:56 AM Hubert Tong via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> On Fri, Jun 19, 2020 at 12:32 PM Anton

Hi Manuel, > 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. sorry for the silly question but... how do you sign up? The "sign up" section doesn't have a "sign up here" link. It