similar to: Multi-Threading Compilers

On 2/28/20 12:19 AM, Chris Lattner wrote: > Hi Nicholas, > > You might want to check out MLIR: its pass manager is already automatically and implicitly multithreaded. > > -Chris Chris, I was aware that LLVM was moving to MLIR at some point due to this. I've curious as to how MLIR deals with IPO as that's the problem I was running into. Even if you have pipelines what

On 2/28/20 12:56 AM, Chris Lattner wrote: > On Feb 27, 2020, at 9:44 PM, Nicholas Krause <xerofoify at gmail.com > <mailto:xerofoify at gmail.com>> wrote: >> On 2/28/20 12:19 AM, Chris Lattner wrote: >>> Hi Nicholas, >>> >>> You might want to check out MLIR: its pass manager is already >>> automatically and implicitly multithreaded.

On Sat, Feb 29, 2020 at 4:00 PM Nicholas Krause <xerofoify at gmail.com> wrote: > > > On 2/29/20 6:17 PM, River Riddle via llvm-dev wrote: > > > > On Sat, Feb 29, 2020 at 2:25 PM David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> >> On Sat, Feb 29, 2020 at 2:19 PM Chris Lattner <clattner at nondot.org> >>

On Sat, Feb 29, 2020 at 5:14 PM Nicholas Krause via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On 2/29/20 7:23 PM, River Riddle wrote: > > > > On Sat, Feb 29, 2020 at 4:00 PM Nicholas Krause <xerofoify at gmail.com> > wrote: > >> >> >> On 2/29/20 6:17 PM, River Riddle via llvm-dev wrote: >> >> >> >> On Sat,

On Sat, Feb 29, 2020 at 2:25 PM David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Sat, Feb 29, 2020 at 2:19 PM Chris Lattner <clattner at nondot.org> wrote: > >> On Feb 29, 2020, at 2:08 PM, David Blaikie <dblaikie at gmail.com> wrote: >> >> I've >>> curious as >>> to how MLIR deals with IPO as that's

On Feb 29, 2020, at 2:08 PM, David Blaikie <dblaikie at gmail.com> wrote: > I've > curious as > to how MLIR deals with IPO as that's the problem I was running into. > > FWIW I believe LLVM's new pass manager (NPM) was designed with parallelism and the ability to support this situation (that MLIR doesn't? Or doesn't to the degree/way in which the NPM

On 3/3/20 8:37 PM, Chris Lattner wrote: > On Feb 28, 2020, at 6:03 PM, Chris Lattner <clattner at nondot.org > <mailto:clattner at nondot.org>> wrote: >> >> On Feb 28, 2020, at 8:56 AM, Johannes Doerfert >> <johannesdoerfert at gmail.com <mailto:johannesdoerfert at gmail.com>> wrote: >>> On 02/28, Nicholas Krause via llvm-dev wrote:

On Feb 28, 2020, at 8:56 AM, Johannes Doerfert <johannesdoerfert at gmail.com> wrote: > On 02/28, Nicholas Krause via llvm-dev wrote: >> Anyhow what is the status and what parts are we planning to move to >> MLIR in LLVM/Clang. I've not seen any discussion on that other than >> starting to plan for it. > > As far as I know, there is no

On 3/18/20 9:49 AM, Nicolai Hähnle wrote: > On Wed, Mar 18, 2020 at 7:23 AM Nicholas Krause via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> On 3/3/20 8:37 PM, Chris Lattner wrote: >> >> On Feb 28, 2020, at 6:03 PM, Chris Lattner <clattner at nondot.org> wrote: >> >> >> On Feb 28, 2020, at 8:56 AM, Johannes Doerfert <johannesdoerfert at

> On Mar 20, 2020, at 12:34 PM, Nicholas Krause <xerofoify at gmail.com> wrote: > >> >> The problem isn’t constants or functions themselves, it is that they are instances of llvm::Value. Everything that walks a use/def list would have to run code that checks for this, and every call to inst->setOperand() would have to do locking or conditional locking. This would be

On Wed, Mar 25, 2020 at 8:52 AM Doerfert, Johannes <jdoerfert at anl.gov> wrote: > I think the solution space for the value/use-list issue might be larger > than what was mentioned so far. > > > Some random thoughts: > > If no pass ever walks the use list of a constant, except globals which > we could handle differently, we could get rid of their use-list or >

> On Mar 25, 2020, at 5:14 PM, Doerfert, Johannes <jdoerfert at anl.gov> wrote: > >>> Let's assume you >>> walk the uses and we "removed" the use list so there are none, what does >>> that mean. I'd say, nothing much. If you inspect the Value and see it's >>> a Constant you have to assume it has Aliases that denote the same

> On Mar 19, 2020, at 2:31 PM, Johannes Doerfert <johannesdoerfert at gmail.com> wrote: > > I think addressing this issue first makes sense. I would however start > by determining the actual impact of different design choices here. I > mean, do we know locks will be heavily contented? If I had to guess I'd > say most passes will not create or modify functions nor add

> On Mar 26, 2020, at 8:26 AM, Doerfert, Johannes <jdoerfert at anl.gov> wrote: > > On 3/26/20 5:53 AM, Florian Hahn wrote: >>> It also doesn't solve the problem of Functions themselves -- those are >>> also GlobalValues… >> >> >> I am not sure why not. Function passes should only rely on the information at the callsite & from the

We are pleased to announce the first LLVM Cauldron, to be held on Thursday September 8th 2016 in Hebden Bridge, UK. This is the day before the GNU Tools Cauldron being held at the same venue, so we hope to take advantage of the high concentration of compiler enthusiasts and to encourage lots of cross-pollination between communities. This will be a one-day conference with a single talks track and

> On Mar 26, 2020, at 10:19, Nicolai Hähnle via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Mar 25, 2020 at 5:26 PM Florian Hahn <florian_hahn at apple.com> wrote: >> I think one important observation is that most passes currently probably do not really care too much about use lists of various constants, beyond the bookkeeping required to maintain them.

The next Cambridge Social will be pushed a bit further into September, because of the holidays and the LLVM Cauldron. It'd be nice to welcome international LLVMers on the cauldron week. But that also forces the day of the week to be on a Tuesday. With the Cauldron in Hebden Bridge, people will be traveling on Wednesday evening and there would be no point in holding the social then. So, the

Gene Cumm wrote: > On Sat, Dec 12, 2015 at 8:21 AM, Ady via Syslinux <syslinux at zytor.com> wrote: > > > >> On Thu, Dec 10, 2015 at 5:15 PM, Sebastian Herbszt <herbszt at gmx.de> wrote: > >> > Gene Cumm wrote: > >> >> On Tue, Dec 1, 2015 at 3:02 PM, Erwan Velu via Syslinux > >> >> <syslinux at zytor.com> wrote: >

Greetings all, I've been working more on the gcc side with multi-threading it and researching that. However in my time there it seems that both projects can really take advantage of certain C++11 features, most notably std::move, r values, auto and perhaps stronger pointer/floating types. It seems that clang/LLVM are in the same boat and it would help mostly with IR passes or backends

I have a backup server now restoring 6TB of data to a client machine. This has been going on for four days now, and no sign of getting close to completion. The connexion is Gb enet end-to-end, and is running at only 40Mb/s. It has far more capacity than that. The only limiting factor I can see is on the backup server one core of the CPU is running 100% rsync. Clearly rsync is not