similar to: [LLVMdev] "Refactoring" Basic Blocks into a new function

On Apr 19, 2005, at 21:39, Evan Jones wrote: > 1. To mark the section of code to be cut out, I'm using "magic" > function calls (begin() and end()). In order to locate these calls, I > am currently iterating over the basic blocks in a function using the > iterator. Is it possible that I could get the blocks "out of order" > with respect to the control

Hi Guys, I am making another module for Voicemail. I have three fields in a POST form that have to be connected together to make it a single 10 digit number but there is something wrong in my syntax probably. $npaa = "('$_POST[anpa]')"; $nxxa = "('$_POST[anxx]')"; $blocka = "('$_POST[ablock]')"; *$grplist = $npaa.$nxxa.$blocka;*

On Apr 19, 2005, at 22:10, Evan Jones wrote: > I just found the Interval class, and it looks like it could help me > out here. I want to locate the Interval that begins with the call to > the "magic" begin(), and ends with the call to the "magic" end(), if > it exists. If there is no such valid interval, then I want to detect > that and return an error. Can I

Hi, I wrote a Function pass that requires the IntervalPartition pass in order to obtain the set of intervals for every function: virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequired<IntervalPartition>(); } and get a handle to it in the runOnFunction method of my CustomPass: bool CustomPass::runOnFunction(Function& F) { IntervalPartition& iPart =

On Aug 27, 2008, at 1:35 PM, Prakash Prabhu wrote: > Hi, > > I wrote a Function pass that requires the IntervalPartition pass in > order to obtain the set of intervals for every function: > > However when i access the intervals vector for a particular call of > runOnFunction, it seems that alll intervals computed for the earlier > functions are still in the > vector. To

On Fri, 29 Apr 2005, Vladimir Prus wrote: > it looks like the IntervalPartition does not work as expected when constructed > from another interval partition. > > Say, I have built an interval partition from function, and the first interval > has two basic blocks. When I create second order partition and print all > intervals, the second basic block of the function is not seen

Hi, it looks like the IntervalPartition does not work as expected when constructed from another interval partition. Say, I have built an interval partition from function, and the first interval has two basic blocks. When I create second order partition and print all intervals, the second basic block of the function is not seen anywhere. Here's what's going on in IntervalIterator.h:

ValGrind gives me some info, but I'm not great at memory stuff, and so I'm not sure what to make of it... This is code that worked for someone 8 months ago, and I'm just trying to get it to run on llvm 2.9 instead of 2.8, so the fact that it hasn't been working is frustrating. Anyway, my issues seem to stem from IntervalIterator, as seen below. I have a lot of similar issues

On Apr 19, 2005, at 8:39 PM, Evan Jones wrote: > I have two very specific questions about LLVM, but first let me give > you the general overview of what I am trying to achieve. I have some > section of a function that I want to replace with a function call to a > brand new function. For example, I want to take the following > function: > > function foo: > code A >

On Fri, Feb 3, 2012 at 1:20 PM, Griffin Wright <grwright at umich.edu> wrote: > > Hello, > > I've been stuck with a problem for about a month, and it has stumped > everyone in my lab.  I have a function pass that runs, and when it finishes > and opt goes to return, I get: > > While deleting: void % > An asserting value handle still pointed to this value! >

Hi Chris, Thanks for the reply. I am actually interested in using the Intervals Analysis mainly to be able to do Region based analysis. In fact, I found that the way Intervals are defined mirror exactly the definition of a Region in the second edition of the Dragon Book (Section 9.7 on Region-Based Analysis), so it will be great if the Intervals related code still lives on in LLVM :). I found

Hello, I've been stuck with a problem for about a month, and it has stumped everyone in my lab. I have a function pass that runs, and when it finishes and opt goes to return, I get: While deleting: void % An asserting value handle still pointed to this value! UNREACHABLE executed at /x/grwright/llvm/llvm-2.9/lib/VMCore/Value.cpp:569! On a simple test case, the error becomes 'i32 %'

On Saturday 30 April 2005 07:30, Chris Lattner wrote: > > Here's NodeTy is a first order interval and can contain several basic > > blocks, but we add only the first one. I attach the patch which tries to > > fixes that. Also, for convenience, there's output of 2-order interval on > > some test case. 'log' is before the change and 'log_good' is

On Aug 27, 2008, at 3:04 PM, Prakash Prabhu wrote: > Hi Chris, > > Thanks for the reply. I am actually interested in using the Intervals > Analysis mainly to be able to do Region based analysis. In fact, I > found that the way Intervals are defined mirror exactly the definition > of a Region in the second edition of the Dragon Book (Section 9.7 on > Region-Based Analysis),

Is there structural analysis as described in Advanced compiler design & implementation(Muchnick) in LLVM now? I only find interval analysis in IntervalPartition.cpp now. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070312/5b6ea365/attachment.html>

On Apr 19, 2005, at 23:17, Vikram Adve wrote: > Have you looked at ExtractCodeRegion() and its siblings in > include/llvm/Transform/Utils/FunctionUtils.h? It seems to be what you > need. This is brilliant. In fact, it is nearly *exactly* what I need. On Apr 19, 2005, at 23:59, Chris Lattner wrote: > An Interval (and an Interval partition) is a concept with a lot of > compiler

Hello Gluster folks, gluster-block [1] release 0.2.1 is tagged, this release is more focused on bug fixing. All the documents are updated and packages made available at copr for fedora users [2] However for other distros one can easily compile it from source, find the install guide at [3] The source tar file and community provided packages will be soon made available at [4] Highlights:

Hope to get some attention about this idea to reduce hacking passwords. Here is a list of about 700,000 IP addresses that are hacking passwords through SMTP AUTH http://ipadmin.junkemailfilter.com/auth-hack.txt This is a list of IP addresses that attempted to authenticate against my fake AUTH advertizing on servers with no authentication. We do front end spam filtering for thousands of

> > - gcc bug > > - problem with SuSE distribution > > One of these two. In theory GCC should never crash (even if the LLVM > sources had problems), and since SuSE made modifications to the compiler > before they shipped it, they implicitly took responsibility for the end > result. I agree. > You can try sending a bug report to SuSE. hm, sending bug report is

Hello All, I have some data tied to the basic blocks in a function, and after inlining that function, I'd like to recover that data in the inlined version. Is there some way to match up the inlined version of the function with the original basic blocks? Thanks, Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: