similar to: [LLVMdev] Sethi-Ullman Scheduling

David Greene <dag at cray.com> writes: > What am I missing? Perhaps that this is bottom-up scheduling, so picking the lower-numbered node is the same as picking the higher-numbered node in a top-down scheduler? Just looking for confirmation. Thanks! -Dave

Dear LLVM'ers, I am browsing the instruction schedulers available in llc, and there are many: -pre-RA-sched = {default, none, simple, simple-noitin, list-burr, list-tdrr, list-td} I looked into the sources in lib/CodeGen/SelectionDAG, and I could find implementation of Sethi-Ullman numbering, list scheduling, etc. Now, I wish I could find some comparison between the

On Sep 17, 2013, at 11:04 AM, Ghassan Shobaki <ghassan_shobaki at yahoo.com> wrote: > 1. The SD schedulers significantly impact the spill counts and the execution times for many benchmarks, but the machine instruction (MI) scheduler in 3.3 has very limited impact on both spill counts and execution times. Is this because most of you work on MI did not make it into the 3.3 release?

Hi, I'm trying to implement __builtin_setjmp / __builtin_longjmp for Sparc processors. I think I'm very close, but I can't work out how to issue BuildMI-type instructions to load the address of the recovery location (set in setjmp) into a register using the SETHI / OR combination. I can't see any equivalent code anywhere else in Sparc. I imagine this is similar if I try to make a

Sandeep Patel wrote: > My goal is to have Cortex-A9 support complete in far less than three > months. I've recently gotten some additional help toward that goal, so > the pace should pick up soon. > > As far as compiler texts, there are many newer texts to recommend as > just about all the major optimization passes are done differently > after SSA-form appeared in about

on gk208+ we can simply mov 32bits, so we should have a single mov there Signed-off-by: Karol Herbst <nouveau at karolherbst.de> --- drm/nouveau/nvkm/subdev/pmu/fuc/gf100.fuc3.h | 1598 +++++++++++------------ drm/nouveau/nvkm/subdev/pmu/fuc/gf119.fuc4.h | 1494 +++++++++++----------- drm/nouveau/nvkm/subdev/pmu/fuc/gk208.fuc5.h | 1424 ++++++++++-----------

On Tue, Dec 19, 2006 at 01:31:10PM -0800, Evan Cheng wrote: > > On Dec 19, 2006, at 12:13 PM, Dan Gohman wrote: > > > Hello, > > > > I did a little experiment modifying LLVM to be able to use alias- > > analysis > > information in scheduling so that independent memory operations may be > > reordered. > > I am not sure if it is a good idea to

On Dec 19, 2006, at 12:13 PM, Dan Gohman wrote: > Hello, > > I did a little experiment modifying LLVM to be able to use alias- > analysis > information in scheduling so that independent memory operations may be > reordered. I am not sure if it is a good idea to do this at scheduling time. LLVM explicitly models control flows dependencies as chain operands. This eliminated

Sandeep Patel wrote: > My goal is to have Cortex-A9 support complete in far less than three > months. I've recently gotten some additional help toward that goal, so > the pace should pick up soon. > > As far as compiler texts, there are many newer texts to recommend as > just about all the major optimization passes are done differently > after SSA-form appeared in about

My goal is to have Cortex-A9 support complete in far less than three months. I've recently gotten some additional help toward that goal, so the pace should pick up soon. As far as compiler texts, there are many newer texts to recommend as just about all the major optimization passes are done differently after SSA-form appeared in about 1991. However, for adding Cortex-A8 support, I don't

Hello, I did a little experiment modifying LLVM to be able to use alias-analysis information in scheduling so that independent memory operations may be reordered. Attached is a patch which implements this. I copied some routines from DAGCombiner.cpp for using SDOperands with alias queries; it should probably be factored out somewhere so the code can be shared. I reorganized

Nico Weber <thakis at chromium.org> writes: > On Tue, Nov 1, 2011 at 3:09 PM, David A. Greene <greened at obbligato.org> wrote: >> Óscar Fuentes <ofv at wanadoo.es> writes: >> >>> Okay, we can get rid of recursive make. However, as pointed out >>> elsewhere, removing recursive make will not make a difference on the >>> LLVM build. What

On Sep 29, 2012, at 2:43 AM, Ghassan Shobaki <ghassan_shobaki at yahoo.com> wrote: > Hi, > > We are currently working on revising a journal article that describes our work on pre-allocation scheduling using LLVM and have some questions about LLVM's pre-allocation scheduler. The answers to these question will help us better document and analyze the results of our benchmark

Some distributions default to PIE for their compilers, which on sparc is passed on to the assembler. Since the behaviour of %hi/%lo changes under PIC to become GOT offsets, the current assembly files need adapting to not try to use a GOT offset as an absolute address. --- usr/include/arch/sparc/machine/asm.h | 15 +++++++++++++-- usr/include/arch/sparc64/machine/asm.h | 1 +

Commit-ID: bbef210c8d82202da8cabdd7a329d8e95db2edcc Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=bbef210c8d82202da8cabdd7a329d8e95db2edcc Author: James Clarke <jrtc27 at jrtc27.com> AuthorDate: Wed, 18 Jul 2018 22:30:42 +0100 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Fri, 18 Jan 2019 03:10:14 +0000 [klibc] Fix sparc assembly when

What's a reliable way to prefer one patterns over another? I have two patterns with different predicates. Pattern A has a very general predicate to catch a wide variety of store instructions. Pattern B has a narrower predicate meant to catch very specific store instructions that would also satisfy the predicate for Pattern A. We used to match Pattern B just fine but after changing .td

Óscar Fuentes <ofv at wanadoo.es> writes: > Nico Weber <thakis at chromium.org> writes: > >> On Tue, Nov 1, 2011 at 3:09 PM, David A. Greene <greened at obbligato.org> wrote: >>> Óscar Fuentes <ofv at wanadoo.es> writes: >>> >>>> Okay, we can get rid of recursive make. However, as pointed out >>>> elsewhere, removing

On Monday 15 June 2009 01:32, me22 wrote: > My (possibly faultly) understanding is that intel's has good support > for numerics, presumably through auto-vectorization and such, but only Yes, that's true. > works for intel's architectures and is only excellent on intel chips. That used to be the case, but not so anymore. Intel compilers generate just fine code for AMD

Jim Grosbach <grosbach at apple.com> writes: >> - How difficult do you expect a backport to 3.1 to be? We have to work >> from 3.1. Trunk is too buggy. > You've stated that trunk is too buggy for you to work from on multiple > occasions. Can you elaborate? That doesn't match my experience, as I > install a new compiler on my workstation from a trunk build

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,