search for: moduloschedul

Hi! I can't build LLVM using GCC 4.1 (GCC CVS mainline) after http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050328/025003.html Build terminated with error: /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/SparcV9/ModuloScheduling/DependenceAnalyzer.cpp:25: error: explicit qualification in declaration of `llvm::FunctionPass* llvm::createDependenceAnalyzer()' at line: FunctionPass *llvm::createDependenceAnalyzer() { Removing redundent "llvm::" fix problem. Vladimir

Builds fine on Linux, but there seems to be a problem building it on Cygwin, will look into this. Aaron ----- Original Message ----- From: Aaron Gray To: LLVM Developers Mailing List Sent: Thursday, June 30, 2005 7:12 PM Subject: [LLVMdev] X86AsmPrinter + MASM and NASM backends I have "refactored" the X86AsmPrinter into a number of files ready for the MASM and NASM

Some wheird problem, Target/X86 builds okay now. But there seems to be another problem with the Cygwin build :- make[4]: Entering directory `/usr/build/llvm/lib/Target/SparcV9/ModuloScheduling' llvm[4]: Compiling ModuloSchedulingSuperBlock.cpp for Debug build /usr/src/llvm/lib/Target/SparcV9/ModuloScheduling/ModuloSchedulingSuperBlock.cpp : In member function `virtual bool llvm::ModuloSchedulingSBPass::runOnFunction(l lvm::Function&)': /usr/src/llvm/lib/Target/SparcV9/Modu...

...h.cpp Index: lib/Target/SparcV9/InstrSched/SchedGraph.h Index: lib/Target/SparcV9/InstrSched/SchedGraphCommon.cpp Index: lib/Target/SparcV9/InstrSched/SchedPriorities.cpp Index: lib/Target/SparcV9/InstrSched/SchedPriorities.h Index: lib/Target/SparcV9/LiveVar/BBLiveVar.cpp Index: lib/Target/SparcV9/ModuloScheduling/DependenceAnalyzer.cpp Index: lib/Target/SparcV9/ModuloScheduling/MSSchedule.cpp Index: lib/Target/SparcV9/ModuloScheduling/MSchedGraph.cpp Index: lib/Target/SparcV9/ModuloScheduling/MSchedGraph.h Index: lib/Target/SparcV9/ModuloScheduling/ModuloScheduling.cpp Index: lib/Target/SparcV9/ModuloSch...

...t *P = for (...; ... ; ++P) > *P > > to: > > int *P = ... > for (int i = 0; ... ; ++i) > P[i] > > If you're interested in dependence analysis, the next important step is to > start analyzing distance and direction vectors. You can check out lib/Target/SparcV9/ModuloScheduling/DependenceAnalyzer.cpp It uses Alias Analysis and Scalar Evolution to figure out dependences and distances for single dimensional arrays. It needs more work, but its a start. Its not used by anyone currently. I wrote it for my ModuloScheduling work. -Tanya

Hi, Is it possible to generate a data dependence graph of llvm assembly file? How can I get the data flow information in X.ll file? Also, in .ll file I see everyline ends with something like this: <type> [#uses=3] What is the significance of this and is it used anyway by the compiler for data dependence analysis. I would be grateful for any help. Regards, Manvi

I have "refactored" the X86AsmPrinter into a number of files ready for the MASM and NASM backends to be added. There is a new namespace llvm::X86 to replace the anomonous namespace as this does not work accross mutiple .h and .cpp files. Other than that everything is pritty straight forward, t may possibly need tweeking though. It has been built under MS VS2003, but I am not sure how

...GW32__) ".globl _X86CompilationCallback\n" "_X86CompilationCallback:\n" #else ... #if defined(__CYGWIN__) || defined(__APPLE__) || defined(__MINGW32__) "call _X86CompilationCallback2\n" #else 2.4 alarm()'s in Sparc backend Remove from lib/Target/SparcV9/ModuloScheduling/ModuloScheduling.cpp all calls to alarm(). 3. That's all This should be enough to configure and build LLVM in tools-only mode. Unfortunately, ld crashed while building llc, I'm currently investigating this problem. Also, I'm working on building gcc backend. The results will follow....

On Fri, 17 Jun 2005, Manvi Agarwal wrote: > Hi Chris, Hi. FYI, it's usually better to email the llvmdev list with generic llvm questions. > Is it possible to get control flow graph of the application with the llvm > infrastructure in terms of basic blocks? Yes, given a BasicBlock*, you can iterate over the pred/succ blocks in the CFG like this: #include

On Mon, 18 Jul 2005, Naftali Schwartz wrote: > Hi, everyone. I've been examining llvm for a while and been duly impressed. > I'd like to contribute in the area of dependence analysis, and a good place > to start seems to be in the transformation of pointers to explicit array > accesses. Is anyone else working on this? If not, does this seem a > plausible place to

Hi, everyone. I've been examining llvm for a while and been duly impressed. I'd like to contribute in the area of dependence analysis, and a good place to start seems to be in the transformation of pointers to explicit array accesses. Is anyone else working on this? If not, does this seem a plausible place to start and how would be the best way to go about it? Thanks, Naftali

...euristics or in the generation of the result loop. I’m > definitely still in a learning phase and am poking around to see where we > can customize some things. It might very well come down to the same > decision to write our own pass that implements our own scheduler, and then > utilize ModuloSchedule and an Expander to make changes. One interesting > topic that came up was unrolling to get more utilization of the FUs. > Someone had already identified this optimization in > https://reviews.llvm.org/D53005, but it seems to have gone stale. I’m > also curious about customizing the exp...

...ulo scheduling downstream, distinct from the MachinePipeliner implementation. Historically, MachinePipeliner had very tight coupling between the finding of a suitable schedule and emitting the code that adheres to that schedule. I spent quite a bit of time separating the two; this led to the "ModuloSchedule" and "ModuloScheduleExpander" classes, which we use downstream too (we actually have a minor variant, where we use predication for the prolog and epilog). However, the code that analyzes loops and determines a good schedule is completely custom. It is in this code that we use "...

Hi James, Adding Hendrik, who has taken over ownership of the downstream code involved. I can also add background about the rationale, of that helps? It was added to ignore induction variable update code (scalar code) that is rewritten when we unroll / peel the prolog epilog anyway. Targets like Hexagon or PPC with dedicated loop control instructions for pipelined loops don't need this, but