similar to: [LLVMdev] Source code analysis

Hi All, I think , I was unclear in my last post. I am looking for source code analysis of a program, something similar to what SUIF does. Consider a simple example of Matrix addition A[i][j]+=B[i][j]; I want to know how matrix A is accessed, like whether it is A[i][j] in this case or A[j][i]. Is there anyway in llvm to write a pass to identify this? Can someone give pointers to it? Regards,

Hi, I plan to use LLVM for some compiler transformation. My requirement is that I require a source to source transformation. I need to parse the given program and look for loops. Then I need to create another source file where I can use this source information like the iteration bounds and the loop body into the new file. I was looking at the LoopExtract pass in LLVM passes. However, it enables

On 23 February 2015 at 01:29, Kamal Sharma <kgs1.rice at gmail.com> wrote: > Hi Dibyendu, > > It would be very helpful if you could post the original source code or > snippet. > That way, one can investigate deeper to understand the problem. > > Regards, > Kamal Sharma > Hi Kamal, Sure. I guess I ought to create a test that one can look in isolation. I am

Chris Lattner wrote: > On Tue, 18 Jan 2005, John Cortes wrote: > >> Hi Chris, > > > Hi! I'm CC'ing the llvmdev list for the benefit of others. > >> Since I see you're very involved in LLVM, I need a little guidance on >> getting from C to MACH-SUIF. >> >> I've been given the task of using LLVM to translate C code to another

Chris Lattner wrote: > On Tue, 18 Jan 2005, John Cortes wrote: > >>> Can you say a little bit about MACH-SUIF? With a brief google >>> search, I didn't turn up anything that described the architecture. >>> Is it a RISC-like machine with 32-bit instruction words? >>> >> >> It's another VM representation. I haven't really gotten

On Thu, Jan 20, 2005 at 02:38:39AM -0800, John Cortes wrote: > I tried including the SUIFvm header files and got more errors than I > bargained for. Looks like it hasn't been updated to be portable. I > need some help in getting these suifvm references into the code I'm > writing. While I understand that your current goal is translating LLVM -> SUIF, it seems that

--- David Greene <greened at obbligato.org> wrote: > Roman Levenstein wrote: > > The allocator does not handle register aliases and register classes > > correctly, which makes it rather unusable for most architectures. > One > > idea that can be used for improving handling of irregular > architectures > > is described in the "A Generalized Algorithm for

On Tue, 18 Jan 2005, John Cortes wrote: >> Can you say a little bit about MACH-SUIF? With a brief google search, I >> didn't turn up anything that described the architecture. Is it a RISC-like >> machine with 32-bit instruction words? >> > > It's another VM representation. I haven't really gotten to know the nitty > gritty of the language so

Nikolaos Kavvadias wrote: > Dear friends, > > I have been using the SUIF Machine infrastructure for sometime. Some > optimizations are available without using a target machine, i.e. at the > SUIFvm level. At this level you have "infinite" registers. Other > optimizations, including analyses as for profiling require the use of a > target library, a complete

i don't know the status of nci, but suif/suif2 development and publication is very active. it's will be great if there are tools to transform llvm ir and suif ir to each other. acutally, i didn't use suif but llvm just because suif cannot be compiled by visual studio.net (but visual studio 6). On 5/10/05, Vladimir Prus <ghost at cs.msu.su> wrote: > On Tuesday 10 May 2005

Np, good luck! :) - Stefanos Στις Τρί, 24 Μαρ 2020 στις 8:55 μ.μ., ο/η RITHIK SHARMA < rithiksh02 at gmail.com> έγραψε: > Many thanks, Stefanos! I really appreciate your help :) I heard from > Whitney. > > Best, > Rithik > > On Tue, 24 Mar 2020 at 23:08, Stefanos Baziotis < > stefanos.baziotis at gmail.com> wrote: > >> Hi Rithik, >> >> I

Hi Rithik, CodeMoverUtils is not aimed for only loop transformations, it can be used by any transformation which want to move code or check if code is safe to be moved. It can currently do both hoist and sink but require control flow equivalent between the original location and the intended to be moved location. I would like to keep the API decoupled from loop, so other transformation can use it.

Hi Rithik, I CC'd the 2 other mentors and hopefully you'll get answer. Sorry, but I don't know of any other way to help. :/ You may also try to contact them privately. Best, Stefanos Στις Τρί, 24 Μαρ 2020 στις 7:35 μ.μ., ο/η RITHIK SHARMA via llvm-dev < llvm-dev at lists.llvm.org> έγραψε: > Ping! > I'm bit concern about the approaching deadline next week, some

Roman Levenstein wrote: > Yes, the SUIF allocator (or at least one of them) implements the > Smith/Ramsey/Holloway algorithm. This is what I understand by looking > at the coloring reggister allocator code in the SUIF distribution. The > SUIF code of this allocator is not very well commented, but I'm pretty > sure. Do you have a pointer? I'm interested in this algorithm

Dear friends, I have been using the SUIF Machine infrastructure for sometime. Some optimizations are available without using a target machine, i.e. at the SUIFvm level. At this level you have "infinite" registers. Other optimizations, including analyses as for profiling require the use of a target library, a complete backend. It is very sad, that they have discontinued their MIPS

Roman Levenstein wrote: > The allocator does not handle register aliases and register classes > correctly, which makes it rather unusable for most architectures. One > idea that can be used for improving handling of irregular architectures > is described in the "A Generalized Algorithm for Graph-Coloring > Register Allocation" by Michael D. Smith, Norman Ramsey and Glenn

A couple notes on this: 1. We also need to be able to *read* .o files for linking. Right now we just assume that any symbol not found in a bytcode file is implemented in some native library and will be resolved at runtime. This isn't the greatest assumption. To resolve native binary symbols we need to be able to read native .a, .so, and .o files to ensure the symbols are

Hi Dave, --- David Greene <greened at obbligato.org> wrote: > Roman Levenstein wrote: > > > Yes, the SUIF allocator (or at least one of them) implements the > > Smith/Ramsey/Holloway algorithm. This is what I understand by > looking > > at the coloring reggister allocator code in the SUIF distribution. > The > > SUIF code of this allocator is not very

On Tue, 18 Jan 2005, John Cortes wrote: > Hi Chris, Hi! I'm CC'ing the llvmdev list for the benefit of others. > Since I see you're very involved in LLVM, I need a little guidance on getting > from C to MACH-SUIF. > > I've been given the task of using LLVM to translate C code to another VM > architecture known as MACH-SUIF. For this architecture, i don't

Hello, I am super excited about my proposal being accepted. I would like to thank Whitney for her help during the application phase. I did schedule some tasks for community bonding period. I have started looking into analysis pass for code motion checks. I will keep you updated with the progress. Best, Rithik Sharma -------------- next part -------------- An HTML attachment was scrubbed... URL: