similar to: Machine learning and compiler optimizations: using inter-procedural analysis to select optimizations

Hi Johannes - great we are engaging on this. Some responses now and some later. 1. When you say setup LLVM dev environment +. clang + tools etc, do you mean setup LLVM compiler code from the repo and build it locally? If so, yes, this is all done from my end - that is, I have built all this on my machine and compiled and run a couple of function passes. I have look at some LLVM emits from clang

1. Thanks for the clarifications. I will stick to non-containerized OS X for now. 2. As an aside, I did try to build a Debian docker container by git cloning into it and using the Dockerfile in LLVM/utils/docker as a starting point: - some changes needed to updated packages (GCC in particular needs to be latest) and the Debian image (Debian 9 instead of Debian 8) pretty much sets up the docker

Hi Johannes: 1. Attached is the submitted PDF. 2. I have a notes section where I state: I am still unsure of the GPU extension I proposed as I dont know how LLVM plays into the GPU cross over space like how nvcc (Nvidia's compiler integrates gcc and PTX) does.I dont know if there is a chance that function graphs in the CPU+GPU name spaces are seamless/continupus within nvcc or if nvcc is just

Hi all, My name is Fahad Nayyar. I am an undergraduate student from India. I am interested to participate in GSOC under the project “Improve inter-procedural analyses and optimizations”. I have been using LLVM for the past 8 months. I have written various intra-procedural analysis in LLVM as FunctionPass for my course projects and research projects. But I’ve not contributed to the LLVM

Hi Fahad, > > Improve dynamic memory related capabilities of Attributor. For example > Improve HeapToStackConversions. Maybe such deductions can help safety > (dis)provers. For example, can we improve the use-after-free bug detection > using some attributes? > Stefan should know more about H2S. Regarding the use-after-free, I don't > think there's currently any plans

Hi Farad, > I tried to do this for the NoUnwind attribute Hmm, I don't have experience with this attribute but it seems like a good starting point since it doesn't do much. First of all, be sure that you run with: opt -passes=attributor -attributor-disable=false This uses the new pass manager which is another discussion. Now, to the point: If you open nounwind.ll, it has a bunch of

On 03/16, Fahad Nayyar wrote: > I can see that Johanned have put up some issues for GSOC aspirants. I think > that [2] <https://github.com/llvm/llvm-project/issues/179> ([Attributor] > Cleanup and upstream `Attribute::MaxObjectSize`) will be a very good issue > for me, It seems doable and I can get familiar with the whole process of > writing a patch for an issue. How should I

After I spend some time working with the function attribute* deduction pass** [1,3], I would like to propose a "proper" organization***. Why? Because we do not derive nearly as many attributes as we could****, while we do maintain various (separate and diffently organized) "data-flow-like analyses" to do so. What else? I propose a single optimistic data-flow

----- Original Message ----- > From: "Daniel Berlin via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Joerg Sonnenberger" <joerg at britannica.bec.de>, "llvm-dev" > <llvm-dev at lists.llvm.org> > Sent: Thursday, January 14, 2016 10:38:10 AM > Subject: Re: [llvm-dev] High memory use and LVI/Correlated Value > Propagation > On

Hello Community, I would like to know status of the project and also importance of it. If the project is still open I would like to work on GSoC 2016 proposal for Inter-procedural Register Allocation, in that case please also suggest possible mentor or let me know if anyone is willing to be mentor for this. Sincerely, *Vivek Pandya* -------------- next part -------------- An HTML attachment was

Hi, I used the following commands on the program attached below: llvm-gcc --emit-llvm main.c -c -o main.bc opt -ipconstprop main.bc -o main1.bc diff main.bc main1.bc no difference was o/p :( The Program Segment is as shown below: #include <stdio.h> void f1(int a) { a=a+1; printf("%d",a); } void f2() { int b; b=1; f1(b); } int main() { int

Isn't this effectively the halting problem? Consider the case where block Y is the exit block of main() and block X is the entry block of main(). Jim On Oct 2, 2012, at 4:29 PM, Stephen Schiffli <sschiffli at gmail.com> wrote: > Is there any inter-procedural analysis that could tell me if some BasicBlock Y is guaranteed to execute based on my knowledge that BasicBlock X will

Hi, I want to see the output of a InterProcedural Constant Propagation Pass IPCP in llvm. I have llvm 2.8 installed.And i used opt -print-after-all command to see the .bc output generated after each pass. However,this does not include dump produced by IPCP :( why? Kindly tell me how to view dump produced by IPCP. P.S: i have tried opt -ipcp src.bc -o src1.bc However the src.bc and src1.bc both

> On Mar 24, 2016, at 1:55 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> One more, just for fun: Inter-procedural stack allocation. That is of calls bar, bar needs 4 bytes of stack space. Instead of bar allocating 4 bytes, it adds an attribute to itself, then foo allocates 4 bytes of space at the bottom of the stack for bar to use. > > This is something that

Hi Vivek, [+CC Matthias, Quentin] Inter-procedural register allocation can be a big win, but my estimate is that it will be challenging to complete within one summer unless you're already familiar with LLVM's register allocator. I've CC'ed some people who can give you some more detailed information. -- Sanjoy On Tue, Feb 9, 2016 at 9:17 PM, vivek pandya via llvm-dev

Is there any inter-procedural analysis that could tell me if some BasicBlock Y is guaranteed to execute based on my knowledge that BasicBlock X will execute? For example: extern int x; void foo() { } int main() { if (x) { foo(); } else { foo(); } } I want to be told that the entry block of foo is guaranteed to be

Hi Suresh, thanks for reporting this! I thought I fixed this with 8d94d3c3b44c3a27a69b153cef9be4b8e481150e. Did you run before or after that commit? Cheers, Johannes On 5/15/20 7:17 AM, Mani, Suresh via llvm-dev wrote: > [AMD Public Use] > > Hi , > > Please ignore the earlier header of Internal and Official use only. > > Thanks > M Suresh > > From: llvm-dev

[AMD Official Use Only - Internal Distribution Only] Hi , There seems to be some issue with attributor, exactly in File Attributor.cpp, Function Attributor::rewriteFunctionSignatures(), Line No: 1600 (approrimate). The llvm source code at above address is as follows: // Eliminate the instructions *after* we visited all of them. for (auto &CallSitePair : CallSitePairs) {

The BlockFrequency analysis has been useful for machine block placement, register allocation and other function-level optimizations. How could we extend it for use in an inter-procedural (whole-program) context? For example, if we would like to compare the hotness of two call sites in different functions, or calculate the hotness of two global variables referenced in multiple functions. If the

Okay thanks for the info. The term program termination was probably a poor choice of words. I'm really just trying to build an inter-procedural BasicBlock graph, and then look for postdominance as Scott suggested. I'll go about making my own since it doesn't sound like there is one out there already. Thanks, -Stephen On Tue, Oct 2, 2012 at 5:06 PM, Scott Moore <sdmoore at