similar to: [LLVMdev] Invalidating an analysis pass

On Jul 25, 2008, at 12:58 PM, Marc de Kruijf wrote: > I'd like to write a pass that does both: implements a code > transformation and saves information that can be accessed by > subsequent passes. Ideally, we want to use two separate pass. However, it is quiet possible that your requirement is unique. Would it be possible to provide more info. on what your pass does ? >

I'd like to write a pass that does both: implements a code transformation *and *saves information that can be accessed by subsequent passes. If such a pass is not an Analysis pass and that therefore subsequent passes are not supposed to use getAnalysis() to extract the information from that pass... what is the right way to do this? Right now I am using getAnalysis to get the information from

On Fri, 22 Sep 2006, Ryan M. Lefever wrote: > In the instructions for writing LLVM passes, it says "[c]urrently it is > illegal for a ModulePass to require a FunctionPass. This is because > there is only one instance of the FunctionPass object ever created, thus > nowhere to store information for all of the functions in the program at > the same time." Right. >

So, am I correct that the implication of what you're saying is that if pass X requires pass Y, then pass Y does not necessarily run to completion on every component of a program, before pass X runs. Furthermore, if those passes X and Y are both function passes, then when pass X runs on function F, the last function Y will have run on is function F. Chris Lattner wrote: > On Fri, 22

In the instructions for writing LLVM passes, it says "[c]urrently it is illegal for a ModulePass to require a FunctionPass. This is because there is only one instance of the FunctionPass object ever created, thus nowhere to store information for all of the functions in the program at the same time." I'm a little confused by that. It was my understanding that if pass X required

On Tue, 4 Jul 2006, Fernando Magno Quintao Pereira wrote: > However, it does not remove all the critical edges. I am getting a very > weird dataflow graph (even without the Break Critical edges pass). The > dataflow generated by MachineFunction::dump() for the program below is > given here: > http://compilers.cs.ucla.edu/fernando/projects/soc/images/loop_no_crit2.pdf ... > The

Hello, This patch fixes PR5382. The problem is that "bu_ls_rr_sort::operator()" and "td_ls_rr_sort::operator()" call getHeight() and getDepth() methods on SUnit, which can recompute values, what invalidates heap (SPQ). This patch guarantees that height and depth values won't be recomputed. The other solution would be to reheapify SPQ everytime when new SUnit is

On Oct 27, 2008, at 3:14 AM, Jay Foad wrote: >>> I'm already working on this myself. Would you be interested in >>> having >>> this work contributed back to LLVM? >> >> If this were to better support target independent languages, it would >> be very useful. If you're just trying to *reduce* the endianness >> assumptions that leak

Devang Patel wrote: > On Jul 25, 2008, at 12:58 PM, Marc de Kruijf wrote: > > I'd like to write a pass that does both: implements a code transformation and saves information that can be accessed by subsequent passes. > > Ideally, we want to use two separate pass. However, it is quiet possible that your requirement is unique. Would it be possible to provide more info. on what

On Jan 4, 2014, at 4:38 AM, Haishan <hndxvon at 163.com> wrote: > At 2014-01-04 06:11:38,"Jakob Stoklund Olesen" <stoklund at 2pi.dk> wrote: > > On Jan 3, 2014, at 1:52 PM, Andrew Trick <atrick at apple.com> wrote: > >> He really just wants to rerun LiveIntervals analysis, but LiveVariables is no longer available. Would it work just to clear all

Hey Everyone! I wanted to carry out Hierarchical clustering using distance matrices i have calculated ( instead of euclidean distance etc.) I understand as.dist is the function for this, but the distances in the dendrogram i got by using the following script(1) were not the distances defined in my distance matrices. script: var<-read.table("the distance matrix i calculated",

On Thu, May 3, 2018 at 3:54 PM, Peter Collingbourne via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Re-sending with trimmed quotation. > > On Thu, May 3, 2018 at 3:52 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> >> >> On Thu, May 3, 2018 at 3:29 PM, David Blaikie <dblaikie at gmail.com> wrote: >> >>> >>>

Hi, thank you for your explanations. In order to get a pre-RA scheduling, I would need something like: - LiveVars - PhiElim - TwoAddr - LiveIntervals - Coalescing - Scheduler (new) - SlotIndexing - LiveIntervals2 (new) - RegAllocMy qeustion then is, is it really so difficult to create the live intervals information, with modifications to the original algorithm, or even from scratch?

Dear R wizards--- I have a wrapper on mclapply() that makes it a little easier for me to do multiprocessing. (Posting this may make life easier for other googlers.) I pass a data frame, a vector that tells me what rows should be recomputed, and the function; and I get back a vector or matrix of answers. d <- data.frame( id=1:6, val=11:16 ) loc <- c(TRUE,TRUE,FALSE,TRUE,FALSE,TRUE)

Re-sending with trimmed quotation. On Thu, May 3, 2018 at 3:52 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > > On Thu, May 3, 2018 at 3:29 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> >> On Thu, May 3, 2018 at 3:08 PM Peter Collingbourne via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> On Thu,

On Thu, May 3, 2018 at 6:03 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > Le jeu. 3 mai 2018 à 15:52, Peter Collingbourne <peter at pcc.me.uk> a > écrit : > >> >> >> On Thu, May 3, 2018 at 3:29 PM, David Blaikie <dblaikie at gmail.com> wrote: >> >>> >>> >>> On Thu, May 3, 2018 at 3:08 PM Peter

On Thu, Nov 25, 2010 at 3:05 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > Kenneth Uildriks wrote: >> >> On Wed, Nov 24, 2010 at 2:50 PM, Nick Lewycky<nicholas at mxc.ca>  wrote: >> >> I thought analysis passes just rebuilt their state after they got >> invalidated.  Shouldn't that happen with an AA pass as well?  Or is AA >> special? >

- Please do not add any more uses of the LiveVariables pass! It is deprecated and only kept around for one last pass that isn't converted. All new code should use LiveIntervalAnalysis! - Kill flags are optional: If they are present they must be correct, but it is legal to have a value die without having a kill flag on the operand. So often a simple fix is to clear out the kill flags from

dear R wizards: I have a large data frame, a million rows, 40 columns. In this data frame, there are some (about 100,000) rows which I want to recompute (update), while I want to leave others just as is. this is based on a condition that I need to compute, based on what is in a few of the columns. what is the right R way to do this? I could subset out the rows that I want to recompute into a

(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