similar to: [LLVMdev] list of LLVM optimization passes

On Jul 6, 2010, at 10:09 AM, Manuel Llosa wrote: > Dear Kenneth, May I ask you if you are implementing your search within > ctuning framework: ctuning.org/ctuning-cc? No, I'm not. I've built my own framework, and since I don't have any experience with the ctuning framework, I don't intend to start using that. There's little gain in it for me. > The thing is that I

Dear Kenneth, May I ask you if you are implementing your search within ctuning framework: ctuning.org/ctuning-cc? The thing is that I use it since some time for my thesis to optimize code size and compilation time and run time with GCC though they are not using genetic algorithms but some slower hybrid of random exploration and than AI with some fronteer detection. Since recent version can be

Dear Kenneth, I see. Do you plan sharing your framework in open source? For now, I will continue using ctuning tools (they support LLVM as is but not some specific things on JIT dynamic recompilation what is my thesis about). I will like to compare all tools of course and will be happy to share results although real not until autumn).Look forward to your results and hopefully keep in touch.

On Jul 6, 2010, at 5:04 PM, Manuel Llosa wrote: > Dear Kenneth, I see. Do you plan sharing your framework in open source? > For now, I will continue using ctuning tools (they support LLVM as is but not > some specific things on JIT dynamic recompilation what is my thesis about). > I will like to compare all tools of course and will be happy > to share results although real not

Tobias Grosser wrote: > The way to go is the scoplib format (propably extended by quantified > variables). This format could be extracted from graphite easily and > could also be created in LLVM. > What we need to get back into LLVM is only the new optimized schedule > described e.g. as cloog like scattering functions. These can be parsed > easily. The real code generation

This is a first step towards to full iterative compilation framework for Clang/LLVM. The attached patch is work in progress and the idea of sending it to the list earlier rather than later is to open up a discussion on iterative compilation in Clang/LLVM. All comments are welcome, especially those related to integration of the framework into Clang/LLVM. Current compilers have pipeline structure

Hal, Thank you for finding interest in our work! Please find my answers inlined below. > > ________________________________________ > From: Hal Finkel [hfinkel at anl.gov] > Sent: Monday, December 16, 2013 4:26 PM > To: Radovan Obradovic > Cc: llvmdev at cs.uiuc.edu; chandlerc; Andrew Trick > Subject: Re: [LLVMdev] [RFC] Iterrative compilation framework for Clang/LLVM >

Radovan, Thanks for posting this! I would really like to have this kind of functionality available. There are a lot of things to think through here; comments inline... ----- Original Message ----- > From: "Radovan Obradovic" <Radovan.Obradovic at imgtec.com> > To: llvmdev at cs.uiuc.edu > Sent: Monday, December 16, 2013 11:31:21 AM > Subject: [LLVMdev] [RFC]

On Fri, Jun 4, 2010 at 8:18 AM, Pekka Nikander <pekka.nikander at nomadiclab.com> wrote: > I am working on heavily optimising unusually static C++ code, and have encountered a situation where I basically want an optimiser that would speculatively unroll a loop to see if the first round of the loop could be optimised further.  (I happen to know that it is possible.)  The previous

Hi Radovan, I am also interested in the iterative compilation in LLVM, and had implemented a simple iterative compilation driver. I guess you do not need to embedded the pointer to ModuleDecisionTreeProxies into the core classes of llvm, i.e. the PassManager class and the Function class. Instead, you could: 1. Implement a special pass manager that runs a set of passes iteratively. Implementing

Hi, I'm noticing that there are some DSNodes in main() that are neither complete nor global. Specifically, a heap DSNode that is used but not free()d in main() is not marked complete. This is not the only case I'm noticing, but it's the only case I'm noticing for nodes that are actually used by instructions in the function. Is this expected behavior? If so, is there an

On 12/27/09 10:18, ether wrote: > hi Tobi , > > that sounds greate :D > > On 2009-12-27 5:43, Tobias Grosser wrote: >> I already looked into implementing something like Graphite for LLVM. >> However just recently, so I have not released any code yet. As soon as >> some code is available I will post patches. > whats its status? do you need any help? Very

I am working on heavily optimising unusually static C++ code, and have encountered a situation where I basically want an optimiser that would speculatively unroll a loop to see if the first round of the loop could be optimised further. (I happen to know that it is possible.) The previous optimisations that produce the loop in the first place already do a magical job (relying heavily on constant

Hi, We have been working on porting llvm-gcc crosscompiler (basically I had to create new dummy target configuration with some minimal information about the our processor, endianess, type sizes, etc.) which compiles llvm bytecode (doesn't compile native binaries nor assembler) for our processor architecture and new llvm target for our custom processor. We already managed to compile also

Good evening, Kenneth. Thank you to apply (and rewrite my naive code better) and to file the issue to http://llvm.org/bugs/show_bug.cgi?id=7304 I have checked r105528 at this morning. I think the pass must be still cleaned up and rewritten. There are my two proposals for enhancement. 1) To separate Specialization(and rewriting callsites) to other module. It would be better if new module were

Good morning, Kenneth FYI, Here is my patch for lib/Transforms/IPO/PartialSpecialization.cpp. It works with my several applications but it is not widely tested. The pass had a critical bug, ... when a specialized function is created, all callers are modified. Even if a caller is not needed, to be malformed. My fix includes to examine each of callers to be modified. See also the discussion;

Applied, with minor changes: 1. deleted[std:distance(as, ai)] creates a map entry (with a null value if the operator[] is not the left-hand-side of an assignment statement) if one doesn't already exist. deleted->find returns deleted.end() if the entry doesn't exist and doesn't change the map. 2. Included a comment to make it easy to find the spot where the callsite is checked

Hello When I compile LLVM trunk with Visual Studio 2008 and cmake, the build is failing because a new file is not yet added to the build system. Attached you can find a patch which fixes the problem for me. Marius Wachtler Index: lib/Transforms/Scalar/CMakeLists.txt =================================================================== --- lib/Transforms/Scalar/CMakeLists.txt (revision 85194)

What is the state of SCCVN pass? It looks like no work is done on it after the initial release. Are there any plans to merge GVN functionality and/or replace GVN pass in the future? Gregory

Hi all, We have 4 outstanding tests on clang-mergefunc-x86_64-freeBSD9.2 builder. I have introduced issues for them in bugzilla: http://llvm.org/bugs/show_bug.cgi?id=18089 http://llvm.org/bugs/show_bug.cgi?id=18056 Since we have opened issues for these tests, can we add them to ignore-list for this builder? It allows faster catch and fix other failures (if we get them). I also wandering, may be