similar to: Regarding the project "Create LoopNestPass"

Hi, Thanks for your help! I've checked the sources that you mentioned. Currently, I think that I would need to implement a FunctionToLoopNestPassAdaptor which is essentially the same as the FunctionToLoopPassAdaptor but operates only on LI.getTopLevelLoops(). We might also need a LNPMUpdater (LoopNestPassManagerUpdater) which disallows adding inner-loops back into the pipeline, and

Hi, I would like to give a quick update on what my current design and implementation go like. Basically, the `FunctionToLoopPassAdaptor` is now modified to a generic version `FunctionToLoopUnitPassAdaptor`, which allows re-using the existing codes to implement `FunctionToLoopNestPassAdaptor`, with the help of additional metadata associated with `Loop` and `LoopNest`. Both

Hi everyone, > I probably do not have the time to get a patch through. IMHO, you do. :) First of all, @Benson sorry but I'm not at all familiar with LLDB so I can't help there. Other than that, I'll also disappoint you both probably because I'm not that familiar with the creation of passes and the problem at hand. I'll try to help as I can. > Is there a specific

Hi Nick, What you said makes sense, but it's not called a call graph. :) You're essentially referring to what LoopInfo does which makes sense, but as I mentioned earlier, this is already done in the LoopInfo. Now, how much one will be able to use it in a LoopNestPass is another issue, which is certainly something that mentors could help you with. Best, Stefanos Στις Τρί, 17 Μαρ 2020

> Yes that's correct. Well, now that I saw the LoopNestAnalysis* files, they try to do sth similar. So, I hope it helped. > My idea was similar but using the call graph directly Personally I don't see how the call graph can help you, since well... it's a call graph. :) You care about loops in a specific function. What can help you is the Control-Flow graph, which is basically

Hi to both, > I'm not applying for GSoC but that's a hint if other students are applying to help them get started. Yes I agree, thanks for bringing up the topic. > On a more serious note, how do I know what issue can be solved in a reasonable amount of time/how do I search for one? Well, usually you don't. If you're lucky, someone will be able to provide you with some

> > IMHO, you do. :) Lol, you have too much faith in me. On a more serious note, how do I know what issue can be solved in a reasonable amount of time/how do I search for one? > Please feel free to email me or Ettore if you encounter any blockers, or > have further questions. Hi Whitney, thanks for the video link and info. I was a bit busy today, but I will work tomorrow and get

Hi Raphael, Thanks for the clarification. I note that in this case, I also think that Benson should preferably find a different project as that would probably be better for everybody. Best, Stefanos Baziotis On Wed, Mar 18, 2020, 12:24 Raphael “Teemperor” Isemann <teemperor at gmail.com> wrote: > Just to clarify my point about the “asking if there is already another > student

Hi Stefanos, First, thanks a lot for the very detailed response! I watched both of the videos, and I seem to have a rough idea now of how each of the different pieces of software maps onto the compilation process. Though I found blogs such as these two: https://jonasdevlieghere.com/understanding-the-clang-ast/, https://releases.llvm.org/2.6/docs/tutorial/JITTutorial1.html to be better for a more

Hi all, It looks like the induction variable simplification pass prefers doing a zero-extension to compute the wider trip count of loops when extending the IV. This can sometimes result in loss of information making ScalarEvolution's analysis conservative which can lead to missed performance opportunities. For example, consider this loopnest- int i, j; for(i=0; i< 40; i++) for(j=0;

Recently I was looking into porting IRCE loop pass into the new pass manager and stumbled on a problem. The problem is due to the existing hard dependency of IRCE on BranchProbability analysis. If I understand it right, in a new pass manager there are only two ways for loop analysis to ask for the result of an "outer" (function/module-level) analysis:   - get it from a predefined

<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div dir="ltr" ><font face="AppleSystemUIFont" size="3" >LoopUnrollAndJamPass is currently a loop pass. It is added in a LPM with only itself.</font><br><font face="AppleSystemUIFont"

Hi Vikram, On Nov 7, 2006, at 10:19 AM, Vikram Adve wrote: > Chris and Devang, > > Before you implement the LoopPassManager class, I'd like to discuss > this a little bit. I have a suggestion and a question; we can > discuss this now or later, as you wish: > > 1. The LoopPassManager might become much simpler if the more complex > loop passes are given control over

Hi All, I am planning to re-implement PassManager in llvm 2.0. The goal is to address http://nondot.org/sabre/LLVMNotes/Inliner-PassManager.txt and http://nondot.org/sabre/LLVMNotes/LoopOptimizerNotes.txt and other crazy ideas Chris has. Current implementation of PassManager is very complex. Initially I attempted to update it to address above notes but realized that redoing

Devang, I read Chris's notes so I got all this information there already. My comments were in response to that. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/ On Nov 7, 2006, at 12:34 PM, Devang Patel wrote: > Hi Vikram, > > On Nov 7, 2006, at 10:19 AM, Vikram Adve wrote: > >> Chris and Devang, >> >> Before you implement the

Hi all, I wanted to give a quick update on the status of NPM for the IR optimization pipeline and ask some questions. In the past I believe there were thoughts that NPM was basically ready because all of check-llvm and check-clang passed when -DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=ON was specified. But that CMake flag did not apply to opt and any tests running something like `opt -foo-pass

Commit-ID: 2c5f70d5fee9a0d51c7fc9a45df99ab735462c62 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=2c5f70d5fee9a0d51c7fc9a45df99ab735462c62 Author: Herbert Xu <herbert at gondor.apana.org.au> AuthorDate: Mon, 6 Oct 2014 19:45:58 +0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Fri, 25 Jan 2019 02:57:21 +0000 [klibc] [BUILTIN] Do not allow

Commit-ID: 76fe43c4a495381c5e5600f127bb03f3b26b0d94 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=76fe43c4a495381c5e5600f127bb03f3b26b0d94 Author: Herbert Xu <herbert at gondor.apana.org.au> AuthorDate: Mon, 6 Oct 2014 19:45:58 +0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 28 Mar 2020 21:42:54 +0000 [klibc] dash: [BUILTIN] Do not

After talking with some NPM people, I believe the ultimate goal after NPM is enabled by default is to only support `-passes=`, and remove support for `-foo-pass`. However, until NPM is enabled by default, we still want tests using opt to use the legacy PM by default. We could attempt to make `-passes=` work with the legacy PM and have a legacy vs new PM flag, but given the design/syntax of

Chris and Devang, Before you implement the LoopPassManager class, I'd like to discuss this a little bit. I have a suggestion and a question; we can discuss this now or later, as you wish: 1. The LoopPassManager might become much simpler if the more complex loop passes are given control over how they iterate over the loops, rather always rely on the manager to enumerate the loops in