search for: manycore

Hello everyone, We are working on extending RISC-V LLVM backend which will help us to achieve the goal of improving programmability in the second generation design of our open source RISC-V manycore processor (bjump.org/manycore). We started with supporting 64 bit pointers in RISCV 32 bit backend using address spaces and register pairs. We aim to support 64 bit pointers in address space 1 using a pair of i32 registers. The 64 bit address will be stored in two i32 registers and we will add cus...

...via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > Hello everyone, > > > > We are working on extending RISC-V LLVM backend which will help us to > achieve the goal of improving programmability in the second generation > design of our open source RISC-V manycore processor (bjump.org/manycore). > > > > We started with supporting 64 bit pointers in RISCV 32 bit backend using > address spaces and register pairs. We aim to support 64 bit pointers in > address space 1 using a pair of i32 registers. The 64 bit address will be > stored in two...

Hey compiler peeps, Cray is ramping up a number of exciting projects and we're looking for new hires. Obviously parallelism has been our core focus, but the challenges of manycore and accelerator technology are presenting new twists requiring us to bring new solutions to bear. After the successful launch of the Jaguar machine (the fastest for open science, http://www.cray.com/Products/XT/Product/ORNLJaguar.aspx) we're working toward the next leap in computational power....

...hat things are valid targets is spread over multiple files with subtle interactions between them. Agree a CMake build system is desirable. Some of the perl configure and generation code is ingrained and might have to stay around longer. > > We have a number of people producing experimental manycore 64-bit MIPS systems running FreeBSD, so we'd also be interested in doing MIPS bring-up, but the build system is currently something of a show-stopper for us. The port is working on FreeBSD 10 x86_64 (modulo CPU affinity support) so MIPS shouldn't be a large leap from there, hopefully this...

> Why do you want this? The goal is to share arrays between multiple tiles on a manycore architecture by splitting arrays between tiles. With a DRF memory model, it makes sense to elide multiple loads to the same memory location between barriers.; IIRC the semantics for volatile don’t allow this eliding. -------------- next part -------------- An HTML attachment was scrubbed... URL: &l...

...Creating the %d map',i)); GaussRF(x=x, y=y, model=model, grid=TRUE,param=c(mean,variance,nugget,scale,Whit.alpha)) } ) ) user system elapsed 1816.784 296.745 1062.142 ------------------------------------------- C.Case. Foreach is considered to be easier to be applied to manycores. foreach (i=1:dimz) %do% { print(sprintf('Creating the %d map',i)); Shadowlist[,,i]<-f <- GaussRF(x=x, y=y, model=model, grid=TRUE,param=c(mean,variance,nugget,scale,Whit.alpha)) } user system elapsed 1027.058 13.243 1031.849 ------------------------------...

...ois at Urbana-Champaign http://llvm.org/~vadve On Jul 8, 2009, at 3:59 PM, David Greene wrote: > Hey compiler peeps, > > Cray is ramping up a number of exciting projects and we're looking > for new hires. Obviously parallelism has been our core focus, but > the challenges of manycore and accelerator technology are presenting > new twists requiring us to bring new solutions to bear. > > After the successful launch of the Jaguar machine (the fastest for > open science, http://www.cray.com/Products/XT/Product/ORNLJaguar.aspx) > we're working toward the next leap...

All: Sorry if this is a bit off-topic, but... having two successful workshops at Supercomputing, I'm contemplating a third (I'm a glutton for punishment.) This year, the focus will be on many/multicore's programmability gap -- the gap between today's languages and the multicore/manycore architectures that we're trying to program. A stellar example is software development on the IBM Cell BE and its SPUs in C/C++. The workshop will focus on languages, compilers and runtimes that are targeted for many/multicore architecutes and platforms. If you know of any good speakers with t...

On Thu, Jul 11, 2019 at 10:42 PM Tim Northover <t.p.northover at gmail.com> wrote: > On Thu, 11 Jul 2019 at 18:03, Reshabh Sharma <reshabhsh at gmail.com> wrote: > > Ah now I could see it more clearly. I was not sure that should I add > them (MO_LO32_LO and MO_LO32_HI), btw this was backup plan. Probably for > now we are going with this. I implemented them today and

...marks * Application-level libraries on clusters * Effective use of clusters in novel applications * Performance evaluation tools Area 2: Architecture, Network/Communications, and Management * Energy-efficient cluster architectures * Node and system architecture * Packaging, power and cooling * GPU/ManyCore and heterogeneous clusters * Interconnect/memory architectures * Single system image clusters * Administration and maintenance tools Area 3: Programming and System Software * Cluster System Software/Operating Systems * Cloud-enabling cluster technologies and virtualization * Energy-efficient middl...

...marks * Application-level libraries on clusters * Effective use of clusters in novel applications * Performance evaluation tools Area 2: Architecture, Network/Communications, and Management * Energy-efficient cluster architectures * Node and system architecture * Packaging, power and cooling * GPU/ManyCore and heterogeneous clusters * Interconnect/memory architectures * Single system image clusters * Administration and maintenance tools Area 3: Programming and System Software * Cluster System Software/Operating Systems * Cloud-enabling cluster technologies and virtualization * Energy-efficient middl...

...th the build system and the OpenMP runtime itself. I'll see if we can contribute this upstream in the next few days. > > This work generalises a few abstractions to ease porting to other platforms as well. That's awesome! >> We have a number of people producing experimental manycore 64-bit MIPS systems running FreeBSD, so we'd also be interested in doing MIPS bring-up, but the build system is currently something of a show-stopper for us. > > The port is working on FreeBSD 10 x86_64 (modulo CPU affinity support) so MIPS shouldn't be a large leap from there, hopef...

So, volatile’s been a fine solution — the issue is volatile pointers would perform the load every time; ideally memory accesses would be able to be cached. This is why I’ve been leaning towards disabling the part of instcombine that combines memory accesses instead of using volatile — there should be better performance. On Apr 17, 2019, 9:54 AM -0700, Jameson Nash <vtjnash at gmail.com>,

Now that we've kick-started the LLVM OpenMP runtime discussion, I want to make a concrete proposal to get a test suite up and running for the LLVM OpenMP runtime. I don't think the current setup as an LLVM subproject is sustainable going forward without some form of testing support, automated or otherwise. The motivation: It's difficult to make changes to the source without some

A Proposal for adding an experimental IR-level region-annotation infrastructure ============================================================================= Hal Finkel (ANL) and Xinmin Tian (Intel) This is a proposal for adding an experimental infrastructure to support annotating regions in LLVM IR, making use of intrinsics and metadata, and a generic analysis to allow transformations to