similar to: [LLVMdev] alias information on machine instructions

Chris Lattner wrote: > There are a couple of ways to do this. Is your scheduler a prepass > scheduler (before regalloc) or a post-pass scheduler (after regalloc)? it is a post-pass scheduler, which operates on MachineInstrs. we need to run it after register allocation to hide latencies of spill code, prolog, and epilog. > If you want to extract maximal parallelism, I assume you want a

On Mon, 30 Apr 2007, Florian Brandner wrote: > i`m working on a machine instruction scheduler for an VLIW architecture. > loads are somewhat expensive on this architecture, thus i would like to > reorder unrelated loads/stores to better hide load latencies. > > to do this, i would need alias information on machine instructions, > i.e., which machine instructions may access the

On Fri, 4 May 2007, Florian Brandner wrote: > Chris Lattner wrote: >> There are a couple of ways to do this. Is your scheduler a prepass >> scheduler (before regalloc) or a post-pass scheduler (after regalloc)? > > it is a post-pass scheduler, which operates on MachineInstrs. we need to > run it after register allocation to hide latencies of spill code, > prolog, and

Hi Timo, your approach is quite similar to the one in the patch I sent a couple of weeks ago. I also have the Bundle (derivate from MachineInstruction so I call it "MachineInstructionBundle") and pack/unpack so RegAlloc works on the bundles… I really think this is the way to incorporate VLIW support to LLVM. I guess a need for some of this to make to LLVM trunk is to have a backend

On Thursday 03 April 2008 22:00:34 Dan Gohman wrote: > However, for people just interested in post-regalloc scheduling and > VLIW packing and similar things, MemOperands aren't the only approach. > A potentially better way to do this would be to extend MachineInstrs > to preserve the chain dependencies from the SelectionDAG. the selection dag may already contain unnecessary

Hi all, here is the current (unfinished) version of the VLIW support I mentioned. It is a patch over svn rev 141176. It includes the MachineInstrBundle class, and small required changes in a couple of outside LLVM files. Also includes a modification to Mips target to simulate a 2-wide VLIW MIPS. The scheduler is really silly, I did not want to implement a scheduler, just the bundle class, and

Hi all, I worked the last 2 years on a LLVM back-end that supports clustered and non-clustered VLIW architectures. I also wrote a paper about it that is currently within the review process and is hopefully going to be accepted. Here is a small summary how I realized VLIW support with a LLVM back-end. I also used packing and unpacking of VLIW bundles. My implementations do not require any

On Wed, May 23, 2007 at 12:23:38AM -0700, Chris Lattner wrote: > On Fri, 4 May 2007, Florian Brandner wrote: > > i had a look at the SelectionDAG based schedulers. it seems that > > aliasing loads/stores are chained together by the DAGCombiner. after > > scheduling, when the MachineInstrs are created, the alias information > > cannot be used anymore in the current

Eli Friedman <eli.friedman at gmail.com> writes: >> Ah. So is the MachineFunction version expected to work correctly? > > It's part of the default set of CodeGen passes. It is? Was that true in 3.1? I can't see where it is initialized in llc. I probably missed something important. :) Thanks! -David

There have been a few queries about this recently, and I've done some work in this area recently, so I'm posting a summary of what the major outstanding issues are. * BasicAliasAnalysis, the default AliasAnalysis implementation, doesn't understand lowered GEPs, integer arithmetic, or PHIs, and the regular codegen process involves passes that lower GEPs. One way to solve this is

Hi Timo, I think any implementation that makes a "bundle" a different entity from MachineInstr is going to be difficult to use. All of the current backend passes will have to taught to know about bundles. Furthermore, if this is something that no current targets are using, then it cannot be adopted into LLVM mainline. I think what we need is a concept of a sequence of fixed machine

http://llvm.org/viewvc/llvm-project/llvm/tags/RELEASE_31/final/lib/CodeGen/Passes.cpp?revision=156747&view=markup void TargetPassConfig::addMachineSSAOptimization() { // Pre-ra tail duplication. if (addPass(EarlyTailDuplicateID) != &NoPassID) printAndVerify("After Pre-RegAlloc TailDuplicate"); /// Add passes that optimize machine instructions after register allocation.

Hi, Thanks for your explanations! How is the big picture for supporting in-order VLIW architectures and the like though? I am asking because I am currently implementing instruction scheduling in our own backend for our custom Patmos processor, for which I need to support both branch delay slots and bundles, some restrictions regarding bundles. For the moment, I am quite happy with a simple

Hi Evan (and all), > I think any implementation that makes a "bundle" a different entity from MachineInstr is going to be difficult to use. All of the current backend passes will have to taught to know about bundles. The approach in the patch I sent (and I believe Timo's code works similar, according to his explanations) is precisely to make "bundles" no different

On Oct 24, 2011, at 2:38 PM, Carlos Sánchez de La Lama wrote: > Hi Evan (and all), > >> I think any implementation that makes a "bundle" a different entity from MachineInstr is going to be difficult to use. All of the current backend passes will have to taught to know about bundles. > > The approach in the patch I sent (and I believe Timo's code works similar,

Hello, I'd like to upstream our work over the time which the community would benefit from. This is a part of effort toward minimizing code size presented in here <https://llvm.org/devmtg/2020-02-23/slides/Kyungwoo-GlobalMachineOutlinerForThinLTO.pdf>. In particular, this RFC is about optimizing prolog and epilog for size. *Homogeneous Prolog and Epilog for Size Optimization, D76570

Evan, Timo, Carlos (and everyone else), I have somewhat similar interest. What would you say to a some sort of a "global cycle" field/marker to determine all instructions scheduled at a certain "global" cycle. That way the "bundle"/packet/multiop can be identified at any time via a common "global cycle" value. I could see that being set first in pre-ra

hi, Florian Brandner wrote: > Dan Gohman wrote: >> On Wed, May 23, 2007 at 12:23:38AM -0700, Chris Lattner wrote: >>> Right. The original Value*'s are preserved in the DAG, but dropped when >>> MachineInstrs are created. We could add a machineoperand to capture this >>> Value* if desired. >> Another benefit of keeping the original Value*'s

Hi Vedant, Thanks for your interest and comment. Size-optimization improves page-faults and a start-up time for a large application, which this enabling also followed. Even though I didn't see a large regression/complaint on a CPU-bound case, which is not a typical case for mobile workload, I wanted to be precautious of enabling it by default. However, as with default outlining case, I

Here are 2 patches, which are independent of each other. The first splits PrologEpilogInserter into 2 parts : http://reviews.llvm.org/D16481 After looking at the code I thought it made more sense for the major split to include whether callee-saved register spills are supported. So for non-virtual targets, virtual registers are not supported and scavenging is optionally supported, and vice versa