similar to: [LLVMdev] RFC: Pass Manager Redux

Hi Chandler, this seems sound to me. For example, consider running function passes. Currently it works like this: if you schedule two function passes in succession, FP1 and FP2, then for each function F, FP1 is run on F then FP2 is run on F. In your new scheme, if you schedule FP1 followed by FP2, then each will act as a module pass and thus: for each function F, FP1 is run on F. Once this is

Sent from my Verizon Wireless 4G LTE DROID On Jun 8, 2016 1:58 PM, Mehdi Amini <mehdi.amini at apple.com<mailto:mehdi.amini at apple.com>> wrote: > > >> On Jun 8, 2016, at 9:32 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >> ________________________________ >>> >>>

On Wed July 11 2012 11:50:01 Chandler Carruth wrote: > - What else did I miss? > > > Things that are totally out of scope: pass registration, the current pass order and structure, the fundamental interface of mapping from a pass to an analysis, etc. This is really about pass management and scheduling. > Hi Chandler, I understand why the pass registration and the pass

On Jul 11, 2012, at 2:50 AM, Chandler Carruth wrote: > In working on a new optimization pass (splitting cold regions into separate functions based on branch probabilities) I've run into some limitations of the current pass manager infrastructure. After chatting about this with Nick, it seems that there are some pretty systematic weaknesses of the current design and implementation (but not

On Wed, Jun 8, 2016 at 12:36 PM, Sanjoy Das via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > Does it make sense to change RefSCCs to hold a list of > RefSCC-DAG-Roots that were split out of it because of edge deletion? > Then one way to phrase the inliner/function pass iteration would be > (assuming I understand the issues): > >

Hi, I need to subset different levels of vector in a dataset to create a new dataframe that contains only these. These observations are not numerical, so I can't use the subset() function (at least this is the response I get from R). Suppose the dataframe looks like this:   ParticipID    ERP   Electrode 1         s1  0.0370       FP1 2         s2 35.0654       FP2 3         s3

> To clarify, we're trying to provide this invariant on the "ref" graph or > on the graph with direct calls only? I think the invariant need only apply > to the former > More clarification needed :) What do you mean by 'invariant need only apply to the former'? > if we're relying on this for correctness (i.e. an analysis must visit all > callees

On Tue, Jun 14, 2016 at 11:29 PM, Xinliang David Li <davidxl at google.com> wrote: > > > On Thu, Jun 9, 2016 at 3:26 AM, Sean Silva <chisophugis at gmail.com> wrote: > >> >> >> On Wed, Jun 8, 2016 at 8:14 PM, Xinliang David Li <davidxl at google.com> >> wrote: >> >>> >>> >>> On Wed, Jun 8, 2016 at 4:38 PM, Sean

On Wed, Jun 8, 2016 at 8:14 PM, Xinliang David Li <davidxl at google.com> wrote: > > > On Wed, Jun 8, 2016 at 4:38 PM, Sean Silva <chisophugis at gmail.com> wrote: > >> >> >> On Wed, Jun 8, 2016 at 12:31 PM, Xinliang David Li <davidxl at google.com> >> wrote: >> >>> >>> >>> On Wed, Jun 8, 2016 at 4:19 AM, Sean

On Wed, Jun 8, 2016 at 12:31 PM, Xinliang David Li <davidxl at google.com> wrote: > > > On Wed, Jun 8, 2016 at 4:19 AM, Sean Silva <chisophugis at gmail.com> wrote: > >> Hi Chandler, Philip, Mehdi, (and llvm-dev,) >> >> (this is partially a summary of some discussions that happened at the >> last LLVM bay area social, and partially a discussion

> On Jun 8, 2016, at 9:32 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > From: "Sean Silva via llvm-dev" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Wednesday, June 8, 2016 6:19:03 AM > Subject: [llvm-dev] Intended behavior of CGSCC pass manager. > > Hi Chandler,

----- Original Message ----- > From: "Sean Silva via llvm-dev" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Wednesday, June 8, 2016 6:19:03 AM > Subject: [llvm-dev] Intended behavior of CGSCC pass manager. > Hi Chandler, Philip, Mehdi, (and llvm-dev,) > (this is partially a summary of some discussions that

On Wed, Jun 8, 2016 at 9:39 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Wed, Jun 8, 2016 at 4:19 AM, Sean Silva <chisophugis at gmail.com> wrote: > >> Hi Chandler, Philip, Mehdi, (and llvm-dev,) >> >> (this is partially a summary of some discussions that happened at the >> last LLVM bay area social, and partially a discussion about

Hi Chandler, Philip, Mehdi, (and llvm-dev,) (this is partially a summary of some discussions that happened at the last LLVM bay area social, and partially a discussion about the direction of the CGSCC pass manager) A the last LLVM social we discussed the progress on the CGSCC pass manager. It seems like Chandler has a CGSCC pass manager working, but it is still unresolved exactly which

On Wed, Jun 8, 2016 at 3:10 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Jun 8, 2016, at 2:54 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Wed, Jun 8, 2016 at 9:39 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > >> >> >> On Wed, Jun 8, 2016 at 4:19 AM, Sean Silva <chisophugis at gmail.com> wrote:

Hello all, It's been a month since my previous email on the topic, and since then I've done some initial work on porting the coroutines passes to the new pass manager. In total there are 6 patches -- that's a lot to review, so allow me to introduce the changes being made in each of them. # What's finished In these first 6 patches, I focused on lowering coroutine intrinsics

For the following code: struct XBeePacket; typedef void (*CompletionProc)(XBeePacket* inPacket, void* inParam2); struct XBeePacket { bool mField1; CompletionProc mCompletionProc; }; Why does clang emit this IR? %struct.XBeePacket = type { i8, {}* } define void @MyCompletionProc(%struct.XBeePacket* %inPacket, i8*

On Mon, Jun 24, 2013 at 2:59 PM, Nadav Rotem <nrotem at apple.com> wrote: > I agree. The vectorizer is a *lowering* pass, and much like LSR and it > loses information. A few months ago some of us talked about this and came > up with a general draft for the ideal pass ordering. > Where? On the mailing list? > If I remember correctly the plan was that the second half of the

On 20.10.2010 05:00, Jakob Stoklund Olesen wrote: > On Oct 19, 2010, at 6:37 PM, Roland Scheidegger wrote: > >> Thanks for giving it a look! >> >> On 19.10.2010 23:21, Jakob Stoklund Olesen wrote: >>> On Oct 19, 2010, at 11:40 AM, Roland Scheidegger wrote: >>> >>>> So I saw that the code is doing lots of register >>>>

(Resending after removing llvmdev at cs.uiuc.edu and using llvm-dev at lists.llvm.org) On Mon, Dec 7, 2015 at 3:08 PM, Easwaran Raman <eraman at google.com> wrote: > Hi Philip, > > Is there any update on this? I've been sending patches to get rid of the > callee hotness based inline hints from the frontend and move the logic to > the inliner. The next step is to use