similar to: [LLVMdev] MachineLoopInfo Analysis Not Done

On Dec 6, 2007, at 5:56 PM, Bill Wendling wrote: > I'm trying to create the Machine LICM pass and I have this defined: > > But when I go to use it: > > bool MachineLICM::runOnMachineFunction(MachineFunction &MF) { > ... > // Get our Loop information... > LI = &getAnalysis<MachineLoopInfo>(); > ... > for (MachineLoopInfo::iterator

Hi:    I want to do some optimization on MachineLoop. So I want to get MachineLoopInfo from MachineFunction. I reference MachineLICM.cpp. So I try to write a pass in Target/mytarget directory. I find there is Error. llvm/include/llvm/PassAnalysisSupport.h:198: AnalysisType& llvm::Pass::getAnalysisID(const llvm::PassInfo*) const [with AnalysisType = llvm::MachineLoopInfo]: Assertion

Thank you, Nick. Yes, I have add getAnalysisUsage. As I know, some CFG is irreducible. At this time, Dominator Tree can not find some backedge. Is it means some MachineLoop is not be found? dominatorTree.jpg is a previous exmaple. best regards! renkun --- 10年3月9日，周二, Nick Lewycky <nicholas at mxc.ca> 写道： > 发件人: Nick Lewycky <nicholas at mxc.ca> > 主题: Re: [LLVMdev] Find

Hi, I'm trying to use the VLIWPacketizerList to schedule instructions for the R600 target, and I'm running into this assertion failure: ScheduleDAGInstrs.cpp:558: Cannot schedule terminators or labels! I think I might not be using the VLIWPacketizerList class correctly. I've attached my code to this email. Can anyone spot what I'm doing wrong? Also, I had to add a LiveIntervals

Hi, One of the long-standing code clean-up bugs in Bugzilla is to extract the Machine* code from the CodeGen library into a separate one, on which CodeGen depends ( http://llvm.org/bugs/show_bug.cgi?id=1121). I'd like to start working on this. The general approach I'm planning to take is: 1. Identify which code to move. 2. Eliminate all dependencies that the Machine code has on the

On Sep 5, 2013, at 5:15 PM, Ken Dyck <kd at kendyck.com> wrote: > Hi, > > One of the long-standing code clean-up bugs in Bugzilla is to extract > the Machine* code from the CodeGen library into a separate one, on > which CodeGen depends ( > http://llvm.org/bugs/show_bug.cgi?id=1121). > > I'd like to start working on this. The general approach I'm planning

Dear all, I found many methods (such as getTripCount, isLCSSAForm) are not supported for machine loops in MachineLoopInfo.h file. Does this mean I can not use MachineLoopInfo if I need getTripCount? Why not support them in MachineLoopInfo? Thank you!

Antony Blakey wrote: > SVN head LLVM and Clang built out of the box for me a week ago on > MSYS/MINGW, using the following files: Ok, I tried to do the same. The compilations stops with the following error message (actually, I got to the same point in my attempt to build LLVM with the MinGW compiler shipped with Cygwin): llvm[1]: Compiling MachineLoopInfo.cpp for Debug build

Hi, guys, what is the interface for finding the immediate dominator of a machine basic block in LLVM 2.1? I found some methods to check if a node dominates other in llvm::MachineDominatorTree, but I was looking for something like: MachineBasicBlock * mbb = ... MachineBasicBlock * iDom = XXX->getImmediateDominator(mbb); is there something similar? best, Fernando

Hi, I read your post in LLVM forum. I want to use getAnalysisUsage(AnalysisUsage &AU) to get MachineLoopInfo. I have used this on my passes before but, this time I am trying to get this information in ScheduleDAGRRList scheduler class. There is no runonmachinefunction function. Do you know how I can implement this? Regards, Fateme I will appreciate it you can help me with this problem.

What are the correct target description side effect flags for instructions which may trap (e.g. divide / remainder)? The divide instruction in my backend currently has no flags set. I've enabled the MachineLICM pass and it's causing a miscompilation by hoisting a divide by zero instruction out of the loop. Clearly this pass needs to be made aware that this is not safe. The current

Hi: I hope to cut all backedges of MachineFunction CFG, then topological sort MachineBasicBlocks. 1. MachineDominatorTree *domintree = new MachineDominatorTree(); domintree->runOnMachineFunction(mf); 2. Then travel mf one by one. When domintree->dominates(next,current) is true, there is a backedge from current node to next node. move this backedge form CFG. But I find A LOOP in

Thanks for the tip! I looked into it and it looks like the problem as of SVN HEAD is that the lui and ori instructions in Mips are considered cheap (1-cycle def-use latency) by MachineLICM::IsCheapInstruction(), but are not trivially materializable because their register operands are not always available. This makes MachineLICM::IsProfitableToHoist() return false, preventing the hoist even

Hi: I hope to cut all backedges of MachineFunction CFG, then topological sort MachineBasicBlocks. 1. MachineDominatorTree *domintree = new MachineDominatorTree(); domintree->runOnMachineFunction(mf); 2. Then travel mf one by one. When domintree->dominates(next,current) is true, there is a backedge from current node to next node. move this backedge form CFG. But I find A LOOP in

2010/1/25 任坤 <hbrenkun at yahoo.cn>: > Hi: > > I hope to cut all backedges of MachineFunction CFG, then topological sort MachineBasicBlocks. > > 1. MachineDominatorTree *domintree = new MachineDominatorTree(); > domintree->runOnMachineFunction(mf); > > 2. Then travel mf one by one. > When domintree->dominates(next,current) is true, there is a backedge

Jay Foad wrote: >> I'm linking a program (my ellsif driver) that basically brings in most >> of the LLVM stuff: bitcode reading, optimizations, linking, and target >> code generation. >> >> All of a sudden, I'm getting the following when I run: >> [~/elsa/ellsif] dev% ./ellsif -v test/ofmt.i test/sieve.i -time-actions >> -O5 >>

On Wednesday 11 July 2007 15:07, Christopher Lamb wrote: > Could it be possible for there to be a harness type interface that > would allow coalescers that support both modes to be hooked into the > pass registration, and those that depend on the allocator not be > registered as passes? I have a patch for this kind of thing attached. Please take a look and let me know if it looks

On Jul 6, 2008, at 4:30 AM, Richard Pennington wrote: > OK, I finally found my problem. (Which means I took the time to > track it > down.) At first glance I thought the above patch would work. It > didn't. > > What it turned out to be is: > > ./lib/CodeGen/LLVMTargetMachine.cpp:41 > EnableLICM("machine-licm", > cl::init(false),

Hi Arnaud, Thanks for following up with that and sorry for the breakage. Couple of comments: MachineLoopInfo *MLI; + RegScavenger *RS; Would it make sense to use a unique_ptr here? That should eliminate the need of having explicit deletes. +; RUN: llc -mtriple=aarch64-linux-gnu -o - %s Add -enable-shrink-wrap=true and a second RUN line with -enable-shrink-wrap=false. Then add check lines

Thanks again. I executed the following command line llc -O3 comb.ll.bc -debug-pass=Arguments and got Pass Arguments: -targetdata -targetpassconfig -no-aa -tbaa -targetlibinfo -basicaa -collector-metadata -machinemoduleinfo -machine-branch-prob -preverify -domtree -verify -loops -loop-simplify -scalar-evolution -loop-simplify -iv-users -loop-reduce -gc-lowering -unreachableblockelim