similar to: [LLVMdev] PassManager error message hard to decipher

Say I want to find all LLVM Value*-es that a live on exit from a basic block. What's the best way? - The 'LiveRange', 'LiveVariables' and 'LiveIntervals' classes seem to be tied to register allocation. - The ./lib/Target/SparcV9/LiveVar/FunctionLiveVarInfo.h file seem to provide what I need, but it's no a public header. - Volodya

On Wed, 11 May 2005, Alkis Evlogimenos wrote: > On Wed, 2005-05-11 at 13:17 -0500, Chris Lattner wrote: >> On Wed, 11 May 2005, Vladimir Prus wrote: >>> Say I want to find all LLVM Value*-es that a live on exit from a basic block. >>> What's the best way? >>> >>> - The 'LiveRange', 'LiveVariables' and 'LiveIntervals' classes

This occurs when a header file is moved or deleted. The dependency files contain the old header file and produce this error. The only way I have found to get around this is to delete all *.d files when header files are moved or deleted: % cd LLVM_OBJ_DIR % /bin/rm `find . -name '*.d'` If someone knows a better way around this,I'd love to hear it too. --Vikram -----Original

On May 11, 2005, at 3:03 PM, Chris Lattner wrote: > On Wed, 11 May 2005, Alkis Evlogimenos wrote: >> On Wed, 2005-05-11 at 13:17 -0500, Chris Lattner wrote: >>> On Wed, 11 May 2005, Vladimir Prus wrote: >>>> Say I want to find all LLVM Value*-es that a live on exit from a >>>> basic block. >>>> What's the best way? >>>>

On Wednesday 11 July 2007 15:07, Christopher Lamb wrote: > Could it be possible for there to be a harness type interface that > would allow coalescers that support both modes to be hooked into the > pass registration, and those that depend on the allocator not be > registered as passes? I have a patch for this kind of thing attached. Please take a look and let me know if it looks

Hello, all I''m "playing" with ZDB again on another test system, the rpool being uncompressed with 512-byte sectors. Here''s some output that puzzles me (questions follow): # zdb -dddddddd -bbbbbb rpool/ROOT/nightly-2012-01-31 260050 ... 1e80000 L0 DVA[0]=<0:200972e00:20200> DVA[1]=<0:391820a00:200> [L0 ZFS plain file] fletcher4 uncompressed

I'm running some code in R64 on a Mac OS 10.6.8 that calls a C program through the dyn.load() function. The code hangs after several days of computation, and I've having trouble locating the problem. Can anyone decipher this info from the error report, and tell me if this is a problem in R64, or in the C code? Thanks very much in advance. A few hints: "pa" is the name of the C

My clients are Windows XP SP1 and SP2, members of a Samba-PDC NT domain (tested 3.0.7 and 3.0.10, same result). Attached is ethereal output of a two packet client-server exchange that takes place when an offline files sync is done. SP1 quickly does this exchange twice - first broadcast, then unicast (as attached) and goes on its way. SP2 tries, pauses many seconds, tries again, finally

Hi David, Sorry I should have replied earlier. I really don't like this dual interface approach. To me, this muddles things without offering any real useful new functionalities. IMHO, if a register coalescer is tied to a particular allocator. Then either it should simply belong to that allocator or that we have to allow the allocator to act as a pass manager itself, i.e. it can

On Jul 17, 2007, at 8:49 PM, David A. Greene wrote: > On Tuesday 17 July 2007 14:21, David Greene wrote: > >>> I don't care for a MachineFunctionPass that can be directly >>> called. I >>> think it's a very good idea to keep the coalescers independent from >>> the allocators. If that's desired, we should enhance passmanager so >>>

Hi David, Just as an idea, you could try to use a coloring register allocator submitted by Bill Wendling some time ago on the mailing list? See this thread for more information http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-April/008489.html This allocator is already implemented using LLVM and could be probably useful for testing your new infrastructure and refactored interfaces. At least

On Tuesday 17 July 2007 14:21, David Greene wrote: > > I don't care for a MachineFunctionPass that can be directly called. I > > think it's a very good idea to keep the coalescers independent from > > the allocators. If that's desired, we should enhance passmanager so > > each allocator can run some sub-passes as part of the allocation > > pass. > >

Hello, My llvm tree doesn't compile; it exits after an error saying: /bin/sh: PreSelection: does not exist while in the lib/CodeGen directory. How can this error be overcome?

On Mon, 2007-07-16 at 16:19 -0700, Evan Cheng wrote: > Property changes on: llvm/include/llvm/CodeGen/RegisterAllocator.h > ___________________________________________________________________ > Name: svn:eol-style > + LF > > What's this? Its a property change. In Subversion every file and directory can have properties associated with them. For example the svn:ignore

On Monday 09 July 2007 17:07, David Greene wrote: > On Monday 09 July 2007 16:49, Reid Spencer wrote: > > The only thing that comes to mind is that creating and running the > > coalescer are separate operations so you might want to do the creation > > of it in alias analysis style. Then, the allocator can a) determine if a > > coalescer was created, b) obtain the

Hello everyone, I noticed that there are several register classes defined in X86 target and many of them are overlapping. Is there a list of all X86 register classes documented somewhere? I found many listed in X86GenRegisterInfo.inc(generated by tablegen) but unsure if that is the complete list. Also, is there documentation on the role and purpose of these classes and how the X86 backend decides

>> Ok, that sounds like a good plan. I'll brush up on how alias analysis >> works and work from there. > > I've been looking at this and it's become clear to me that we need some kind > of abstract coalescing interface similar to what the AliasAnalysis class > provides. I think we need the same thing for register allocators. > > LLVM's existing

On Jul 11, 2007, at 11:39 AM, David Greene wrote: > On Wednesday 11 July 2007 12:41, Tanya M. Lattner wrote: > >> I think the coalescer should be flexible enough to be run >> independent of >> the register allocator. For example, you may want to expose the >> copies >> induced by transforming out of SSA to the scheduler. If the >> scheduler is

Can anyone give me a clue on how to find out more information from this type of error: Oct 17 05:01:08 ara kernel: EXT3-fs error (device sd(8,49)): ext3_readdir: bad entry in directory #8945865: rec_len %% 4 != 0 - offset=0, inode=93580797, rec_len=5963, name_len=106 Oct 17 05:01:08 ara kernel: EXT3-fs error (device sd(8,49)): ext3_readdir: bad entry in directory #8945869: rec_len is smaller

Why is my load stuck around 3? top - 01:19:55 up 146 days, 5:53, 2 users, load average: 3.00, 2.95, 2.52 Tasks: 121 total, 1 running, 120 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0% us, 0.3% sy, 0.0% ni, 99.7% id, 0.0% wa, 0.0% hi, 0.0% si Mem: 1928300k total, 1911640k used, 16660k free, 10760k buffers Swap: 2031608k total, 224k used, 2031384k free, 1561196k cached