similar to: [RFC] Helping release management

Hi Hans, Since you are actively doing this kind of things, your feedbacks is particularly valuable. Thanks! > On May 2, 2016, at 3:45 PM, Hans Wennborg <hans at chromium.org> wrote: > > On Mon, May 2, 2016 at 1:35 PM, Quentin Colombet via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> I am sending this proposal to get feedbacks on how we could make the tagging

> On May 4, 2016, at 4:41 PM, Jim Grosbach <grosbach at apple.com> wrote: > >> >> On May 2, 2016, at 4:03 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi Hans, >> >> Since you are actively doing this kind of things, your feedbacks is particularly valuable. >>

> On May 2, 2016, at 2:05 PM, Smith, Kevin B via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > >> -----Original Message----- >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of >> Quentin Colombet via llvm-dev >> Sent: Monday, May 02, 2016 1:35 PM >> To: llvm-dev <llvm-dev at lists.llvm.org> >> Subject:

On May 2, 2016, at 5:45 PM, Hans Wennborg via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> People shipping compilers based on LLVM may not completely align with the official releases of LLVM. Thus, the stabilization of each custom release may happen at different period of time. Because of that, release managers have to come up with their own strategy to decide which commits should

Filing a PR for *every* fix is overkill. But filing a PR to express "please merge this to the branch" (if there isn't already a PR) seems reasonable. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Reid Kleckner via llvm-dev Sent: Thursday, May 05, 2016 10:09 AM To: Quentin Colombet Cc: llvm-dev Subject: Re: [llvm-dev] [RFC] Helping release

> On May 2, 2016, at 2:48 PM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Mon, May 02, 2016 at 02:39:12PM -0700, Quentin Colombet wrote: >> Hi Joerg, >> >>> On May 2, 2016, at 2:33 PM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> On Mon, May 02, 2016 at 01:35:27PM -0700,

2018-02-13 17:46 GMT-08:00 Mehdi AMINI <joker.eph at gmail.com>: > > > 2018-02-13 13:29 GMT-08:00 Quentin Colombet <qcolombet at apple.com>: > >> Hi Mehdi, >> >> >> On Feb 13, 2018, at 12:34 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: >> >> >> >> 2018-02-08 17:34 GMT-08:00 Quentin Colombet via llvm-dev < >>

On 27 January 2017 at 00:12, Quentin Colombet <qcolombet at apple.com> wrote: > Thanks all the feedbacks. > > I moved forward, the switch happened in r293232. Thanks! > For incremental buildbots, I believe we are going to need to kick a clean > build for them to pick it up. > @Galina, is it something you can do? Unfortunately, no. The logic to re-create the ninja files

Hi Joerg, > On May 2, 2016, at 2:33 PM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Mon, May 02, 2016 at 01:35:27PM -0700, Quentin Colombet via llvm-dev wrote: >> 1. Use [Fix] for commit related to bug fixes. > > I'm not really such a big fan of this format, adds too much noise. What alternatives do you have in mind? >

Hi, With this email, I would like to kick-off the development for the next instruction selector that I described during the last LLVM Dev’ Meeting. For the motivations, see Jakob’s proposal (http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/064727.html <http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/064727.html>) and for the proposal, see the slides (Keynote:

Hi Mehdi, > On Feb 13, 2018, at 12:34 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > 2018-02-08 17:34 GMT-08:00 Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>: > Hi, > > TL;DR > r317488 changed the way fast math flags are laid out in the bitcode and anyone compiling a pre-llvm-6.0 bitcode

Hi all, Following the thread from http://lists.llvm.org/pipermail/llvm-dev/2017-January/109029.html, I am sending this email to give a status on GlobalISel progress and situation. We are pushing GlobalISel from the state of prototype to a production quality framework. We welcome help with patches, reviews, feedbacks and so on. As explained during the last developer meeting, we are aiming at

2018-02-13 13:29 GMT-08:00 Quentin Colombet <qcolombet at apple.com>: > Hi Mehdi, > > > On Feb 13, 2018, at 12:34 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > 2018-02-08 17:34 GMT-08:00 Quentin Colombet via llvm-dev < > llvm-dev at lists.llvm.org>: > >> Hi, >> >> TL;DR >> r317488 changed the way fast math flags are

Hi, I would like to start a discussion about error/warning reporting in LLVM and how we can extend the current mechanism to take advantage of clang capabilities. ** Motivation ** Currently LLVM provides a way to report error either directly (print to stderr) or by using a user defined error handler. For instance, in inline asm parsing, we can specify the diagnostic handler to report the errors

On Fri, Feb 16, 2018 at 8:26 AM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > 2018-02-13 17:46 GMT-08:00 Mehdi AMINI <joker.eph at gmail.com>: > >> >> >> 2018-02-13 13:29 GMT-08:00 Quentin Colombet <qcolombet at apple.com>: >> >>> Hi Mehdi, >>> >>> >>> On Feb 13, 2018, at 12:34 PM, Mehdi AMINI

Hi, > I found this thinking quite difficult to explain. Does it make sense? It might help to link to the documentation on why bitcasts are weird on big-endian NEON: http://llvm.org/docs/BigEndianNEON.html#bitconverts Cheers, James On Tue, 12 Jan 2016 at 13:23 Daniel Sanders via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > > > I haven't found much time to

Hi Daniel, I had a quick look at the language reference for bitcast and I have a different reading than what you were pointing out. Indeed, my take away is: "It is always a no-op cast because no bits change with this conversion." In other words, deleting all bitcast instructions should be fine. My understanding of the quote you’ve highlighted is that it tells C programmers that this

Hi Daniel, Thanks for the pointers, I wasn’t aware of the second thread you’ve mentioned. I may be wrong but I think LLVM-IR optimizations really treat bistcasts as no-op casts, in the sense of no instructions are required. Is there anyone that could chime in on that? However, it seems SelectionDAG sticks to the load/store semantic: "BITCAST - This operator converts between integer,

According to the schedule (e.g. on the right on llvm.org), we should have tagged the release by now, but we haven't, so we're officially behind schedule. I'm still optimistic that we can wrap this up pretty soon, though. This is what's blocking us: - PR26509: Crash in InnerLoopVectorizer::vectorizeLoop() I'm waiting to hear what Cong comes up with, otherwise we can revert

What happens when you cascade bitcast? Are these sequences all equivalent at the IR level (i.e. do they reference the same byte from the original i128)? i128 => <16 x i8> => GEP 0 i128 => <2 x i64> => GEP 0 => <8 x i8> => GEP 0 i128 => <2 x i64> => GEP 0 => <2 x i32> => GEP 0 => <4 x i8> => GEP 0 —