similar to: [RFC] 'Review corner' section in LLVM Weekly

On Mon, Aug 28, 2017 at 8:04 AM, Alex Bradbury <asb at asbradbury.org> wrote: > On 27 August 2017 at 00:01, Alex Bradbury <asb at asbradbury.org> wrote: >> Hi all. I'm assuming most people reading this email are familiar with LLVM's >> code review process <http://llvm.org/docs/DeveloperPolicy.html#code-reviews> >> as well as LLVM Weekly, the

On 27 August 2017 at 00:01, Alex Bradbury <asb at asbradbury.org> wrote: > Hi all. I'm assuming most people reading this email are familiar with LLVM's > code review process <http://llvm.org/docs/DeveloperPolicy.html#code-reviews> > as well as LLVM Weekly, the development newsletter I've written and sent out > every Monday since Jan 2014. Since that time,

Hi all, Some discussions the night before prompted me to do a short lightning talk on 'improving the experience of first-time contributors' at the LLVM Cauldron back in September. I intended to write it up as an RFC, but have only just got round to doing so. I've tried to make this email self-contained, but you may still want to look at the slides or recording of the lightning talk.

> > Only a single LGTM is required. Reviewers are expected to only LGTM > patches they're confident in their knowledge of. Reviewers may review > and provide suggestions, but explicitly defer LGTM to someone else. > This is encouraged and a good way for new contributors to learn the code. Whilst I get what you're trying to say, I'm not particularly comfortable with

Hi, everyone, I've been fielding an increasing number of questions about how our code-review process in LLVM works from people who are new to our community, and it's been pointed out to me that our documentation on code reviews is both out of date and not as helpful as it could be to new developers.   http://llvm.org/docs/DeveloperPolicy.html#code-reviews I would like to compose a

Yeah, +1 that people from the same organization are sometimes the only ones working on a certain feature/area. (certainly I'd expect some discussion about the feature in general to be discussed outside that group if it's in any way contentious - but some stuff's clear enough (I think I implemented debug_types years ago, likely with only Eric's approval, both of us being at Google

+1 in general, and Philip has good suggestions as well! -- Mehdi On Sat, Nov 16, 2019 at 8:37 AM Philip Reames via llvm-dev < llvm-dev at lists.llvm.org> wrote: > + 1 in general, a couple of suggestions > > On 11/14/19 7:46 PM, Finkel, Hal J. via llvm-dev wrote: > > Hi, everyone, > > > > I've been fielding an increasing number of questions about how our

On Mon, Dec 2, 2019 at 12:52 PM Philip Reames <listmail at philipreames.com> wrote: > Mehdi, David, > > I think you're both pointing out exceptions rather than the general rule. > I tried to indicate their might be reasonable exceptions (see the second > sentence past Mehdi's quote), but in general, particularly for new > contributors, I think it is important we

----- Original Message ----- > From: "Sean Silva" <chisophugis at gmail.com> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Cc: "Chris Lattner" <clattner at apple.com>, "Rafael Ávila de Espíndola" <rafael.espindola at gmail.com>, "Michael Spencer" > <bigcheesegs at gmail.com>, "Chandler Carruth"

On Mon, Dec 2, 2019 at 8:23 PM Philip Reames <listmail at philipreames.com> wrote: > > On 12/2/19 10:05 AM, David Blaikie wrote: > > > > On Mon, Dec 2, 2019 at 12:52 PM Philip Reames <listmail at philipreames.com> > wrote: > >> Mehdi, David, >> >> I think you're both pointing out exceptions rather than the general >> rule. I tried

https://reviews.llvm.org/D41659 Implemented missing trigonometric optimization in llvm. Here we have implemented the following missing trigonometric optimizations. 1. tan(x)*cos(x)=sin(x) 2. sin(x)*cos(x) = sin(2*x)/2 3. sin(x)/tan(x)=cos(x); 4. tan(x)/sin(x)=1/cos(x); -------------- next part -------------- An HTML attachment was scrubbed... URL:

Dear community, We are trying to setup a BoF ( Raising Next Generation of LLVM Developers, http://sched.co/8Yzs). In our academic-oriented environments the main work force is students: undergrads, grads or PhD (rarely postdocs). Often we have limited time to bring somebody up to speed and we have to it in a productive and motivating for both parties way. I believe most of you had

As you will have seen from previous postings, I've been working on upstream LLVM support for the RISC-V instruction set architecture. The initial RFC <http://lists.llvm.org/pipermail/llvm-dev/2016-August/103748.html> provides a good overview of my approach. Thanks to funding from a third party, I've recently been able to return to this effort as my main focus. Now feels like a good

On Mon, Nov 18, 2019 at 4:53 PM Finkel, Hal J. via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On 11/18/19 4:29 AM, James Henderson wrote: >> >> Only a single LGTM is required. Reviewers are expected to only LGTM >> patches they're confident in their knowledge of. Reviewers may review >> and provide suggestions, but explicitly defer LGTM to someone else.

# Overview and background RISC-V is a free and open instruction set architecture. It is a modular specification, with a range of standard extensions (e.g. floating point, atomics, etc). New standard extensions are developed through RISC-V Foundation working groups. The specifications for such extensions (e.g. vector and bit manipulation) are publicly available, but are still in flux and won't

On Thu, Nov 7, 2019 at 3:09 AM Roman Lebedev via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Strong -1 personally. Likewise, for many of the same reasons detailed below. ~Aaron > * What is the endgoal? To fully kill phab and move to github pullrequests? > it might be best to discuss *that* first. (did i miss an RFC?) > * Separation of attention - does everyone who

LLVM Weekly - #57, Feb 2nd 2015 =============================== If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/57>. Welcome to the fifty-seventh issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. LLVM Weekly is brought to you by [Alex Bradbury](http://asbradbury.org).

Hi all, I am proposing the integration of a backend targeting the RISC-V ISA. RISC-V is a free and open instruction set architecture that was originally developed at UC Berkeley. Future development of the ISA specification will be handled by the 501(c)(6) non-profit RISC-V Foundation and its members <https://riscv.org/membership/?action=viewlistings>. You can find much more information at

At least one proprietary linker put a lot of effort into deduplicating and rewriting debug information. This took up the majority of the link time despite serious engineering time on performance optimisation. For example, some sections were written from scratch by the linker because that proved faster than parsing the input. Teaching LLD to dedup DWARF should be expected to dramatically slow it

Hi all, Now that we're on GitHub, we can discuss about pull-requests. I'd like to propose to enable pull-request on GitHub, as a first step as an experimental channel alongside the existing methods for contributing to LLVM. This would allow to find workflow issues and address them, and also LLVM contributors in general to start getting familiar with pull-requests without committing to