similar to: [LLVMdev] FoldingSetNodeID operations inefficiency

Hi Dan, Thanks for commenting on this topic. See my comments in-line. ----- Ursprüngliche Mail ---- > Von: Dan Gohman <gohman at apple.com> > An: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Gesendet: Mittwoch, den 30. April 2008, 21:38:26 Uhr > Betreff: Re: [LLVMdev] FoldingSetNodeID operations inefficiency > > > On Apr 28, 2008, at 6:21 AM, Roman

Hi Chris, This is a good idea and I started thinking in that direction already. But what I don't quite understand the TFs, how TFs are formed and which rules they should obey to. For example now: > PendingLoads created by the SelectionDAGLowering::getLoadFrom and then copied into the > TokenFactor node by SelectionDAGLowering::getRoot called from the >

Hi, While profiling LLVM using my test-cases with huge MBBs, I noticed that FoldingSetNodeID operations (ComputeHash,insertion,etc) may become really inefficient for the nodes, which have very many operands. I can give you an example of what is meant by "very many". In my test-case (you can fetch it from here http://llvm.org/bugs/attachment.cgi?id=1275), which is just one HUGE MBB

guys, 1)i made a mistake in my post. the said TF node was created when Selected() was called in ADDC node. 2) the source code under test short a,b; void test() { a+=b; } 3)the DAG after ADDC was seleced: Select node: 0x4977a20: ch,glue = <<Unknown Machine Node #65419>> 0x4972bd0, 0x49731d0, 0x4976c20, 0x49730d0<Mem:LD1[@a](align=2)> Result node: 0x4977a20: ch,glue =

Hi, I've looked through the posts but couldn't find a solution to this. I'd be really grateful if someone could help, I'd like to convert a data file of mutual information that is formatted as a matrix:             TF1    TF2    TF3    TF200... Gene1    0.0    0.2    0.2 Gene2    1.4    0.0    2.8 Gene3    0.3    0.6    1.7 Gene6000.... To a list: Gene1    TF1    0.0 Gene1   

Hello, I did a little experiment modifying LLVM to be able to use alias-analysis information in scheduling so that independent memory operations may be reordered. Attached is a patch which implements this. I copied some routines from DAGCombiner.cpp for using SDOperands with alias queries; it should probably be factored out somewhere so the code can be shared. I reorganized

Hi all, Our target does not have native support for 64-bit integers, so we rely on library calls for certain operations (like sdiv). We recently ran into a problem where these operations that are expanded to library calls aren't maintaining the proper ordering in relation to other chains in the DAG. The following snippet of a DAG demonstrates the problem. t0: ch = EntryToken t2:

Following up on my call schedule posting from yesterday, I am now trying to add edges from the call to the instruction before it. This seemed easiest to do in SelectionDAGBuilder but it is troublesome. A couple of questions: - How do I get the previous instruction that was translated? prior(CS.getInstruction()) in visitCall returns something invalid. When I try to call getValue on the

Working on a target I added this pattern: def : Pat<(v4i64 (load xoaddr:$src)), (QVFCTIDb (QVLFDXb xoaddr:$src))>; which represents an actual load followed by a necessary conversion operation. The problem is that when this matches any TokenFactor that was attached to the load node gets attached, not to the inner load instruction, but the outer conversion operation. This is

# read.table is NOT part of the data.table package #library(data.table) DFM <- read.table( text= 'obs start end 1 2/1/2015 1/1/2017 2 4/11/2010 1/1/2011 3 1/4/2006 5/3/2007 4 10/1/2007 1/1/2008 5 6/1/2011 1/1/2012 6 10/5/2004 12/1/2004 ',header = TRUE, stringsAsFactors = FALSE) # cleaner way to compute D DFM$start <- as.Date( DFM$start, format="%m/%d/%Y" ) DFM$end

Thank you Jeff and All, Within a given time period (say 700 days, from the start day), I am expecting measurements taken at each time interval;. In this case "0" means measurement taken, "1" not taken (stopped or opted out and " -1" don't consider that time period for that individual. This will be compared with the actual measurements taken (Observed-

Dear R users, Below I have written 4 functions CIT1, CIT2a and CIT2b and CIT3 which recode a variable CLD_ISCH into 3 new variables(T1 T2 T3), I wish to use T1, T2 and T3 based on the values of tf1 and tf2. (NOTE:- T2a is used to create T2 in a long winded manner due to my lack of programming experience) I then attach T1 T2 and T3 to a dataset KidneyT that contains other variables i wish to use

Hello. I'm having problems at instruction selection with my back end with the following basic-block due to a vector add with immediate constant vector (obtained by vectorizing a simple C program doing vector sum map): vector.ph: ; preds = %vector.memcheck50 %.splatinsert = insertelement <8 x i64> undef, i64 %i.07.unr, i32 0

Since the number of choices is small (6), how about this? Starting with Jeff's initial DFM: DFM <- structure(list(obs = 1:6, start = structure(c(16467, 14710, 13152, 13787, 15126, 12696), class = "Date"), end = structure(c(17167, 14975, 13636, 13879, 15340, 12753), class = "Date"), D = c(700, 265, 484, 92, 214, 57), bin = structure(c(6L, 3L, 5L, 1L, 3L, 1L), .Label

Hello, I've hit an assertion in SelectionDAG where we try to merge 2 loads that have the same operands but their MMO flags differ. One is dereferenceable and one is not. I'm not sure what the underlying issue here is: 1) MDSDNode with the same operands should have the same flags set on their respective MMO. The fact the flags differ when the opcode,types,operands and address-space are

I looked into those patches but I don't think they will help in my situation because my problems occur during instruction selection rather than scheduling. A simple and concrete example is a pattern like: [(set GR:$dst (add GR:$src (nvload addr:$mem)))] where nvload matches a load provided that isVolatile() is false. If the selection DAG looks like: | | LD1 LD2 ^

The current implementation is: void FoldingSetNodeID::AddInteger(unsigned long long I) { AddInteger(unsigned(I)); if ((uint64_t)(int)I != I) Bits.push_back(unsigned(I >> 32)); } (uint64_t)(int)I first truncates I to signed int, which causes the second cast to sign extend the value to 64 bits. The problem is that if the 31st bit of the original value is 1, the sign extended value

While I've not reviewed the patch in too much detail, it looks promising. Can you run some end-to-end benchmarks to make sure that cache pressure in the full program or other variables not accounted for in a micro-benchmark don't dominate performance? Specifically the nightly tester includes a number of real programs and machinery to measure total compile time. On Sat, Feb 6, 2010 at 7:09

On 2010-02-06 17:09, Gregory Petrosyan wrote: > Some additional info can be found at: > > http://murmurhash.googlepages.com/ > http://en.wikipedia.org/wiki/MurmurHash > http://www.codeproject.com/KB/recipes/hash_functions.aspx > > as well as in the patch description itself. Patch and benchmark attached. > > +/// This version additionally assumes that 'len %

On Feb 7, 2010, at 1:03 PM, Gregory Petrosyan wrote: > On Sat, Feb 06, 2010 at 04:51:15PM -0800, Chandler Carruth wrote: >> While I've not reviewed the patch in too much detail, it looks >> promising. Can you run some end-to-end benchmarks to make sure that >> cache pressure in the full program or other variables not accounted >> for in a micro-benchmark don't