search for: srcline

...39;t actually define any value. So we don't > care if a live interval overlaps live ranges defined by an implicit_def. It's a bug because the coalerscer does illegal coaescing. Our last episode left us here: bb134: 2696 %reg1645<def> = FsMOVAPSrr %reg1458<kill> ; srcLine 0 bb74: 2700 %reg1176<def> = FsMOVAPSrr %reg1645<kill> ; srcLine 0 [deleted copy] 2708 %reg1178<def> = FsMOVAPSrr %reg1647<kill> ; srcLine 0 *** u before d 2712 TEST64rr %reg1173, %reg1173, %EFLAGS<imp-def> ; srcLine 30 2716 JLE mbb<fi...

On Jan 30, 2009, at 1:52 PM, David Greene wrote: > On Friday 30 January 2009 15:10, David Greene wrote: > >> This still looks correct. The coalescer then says: >> >> 4360 %reg1177<def> = FsMOVAPSrr %reg1176<kill> ; srcLine 0 >> Inspecting %reg1176,0 = [2702,4362:0) 0 at 2702-(4362) and >> %reg1177,0 = >> [2700,3712:0)[3768,3878:0)[4362,4372:0) 0 at 4362-(3878): >> Joined. Result = %reg1177,0 = [2700,4372:0) 0 at 2702-(4362) >> >> Eh? How can it coalesce these two? Doesn...

...rest is llvm debug output (lots of stuff added by me so you won't get the same output with upstream llvm -debug). ##### There's a sequence of instructions that looks like this before linear scan: ##### 2800 %reg1591<def> = SUB64rr %reg1591, %reg1589, %EFLAGS<imp-def,dead> ; srcLine 0 2808 %reg1591<def> = IMUL64rr %reg1591, %reg1055, %EFLAGS<imp-def,dead> ; srcLine 0 2816 %reg1591<def> = ADD64rr %reg1591, %reg1579, %EFLAGS<imp-def,dead> ; srcLine 0 2820 %reg1198<def> = LEA64r %reg1591, 1, %reg1574, 0 ; srcLine 0 ##### %reg1591 gets spilled b...

On Jan 29, 2009, at 5:29 PM, David Greene wrote: > On Thursday 29 January 2009 18:04, Eli Friedman wrote: >> On Thu, Jan 29, 2009 at 2:47 PM, David Greene <dag at cray.com> wrote: >>> After phi elimination we have: >>> >>> bb134: >>> %reg1645 = 1.0 >>> >>> bb74: >>> %reg1176 = MOVAPS %reg1645 >>> %reg1177 =

On Thursday 29 January 2009 18:04, Eli Friedman wrote: > On Thu, Jan 29, 2009 at 2:47 PM, David Greene <dag at cray.com> wrote: > > After phi elimination we have: > > > > bb134: > > %reg1645 = 1.0 > > > > bb74: > > %reg1176 = MOVAPS %reg1645 > > %reg1177 = MOVAPS %reg1646 > > [...] > > > > bb108: > > %reg1645 =

...ister pressure. Ah, I see. But coalescing seems to break. I don't know if it's because of the eliminated IMPLICIT_DEF, though. Here's what happens. Let's look at this code, annotated with live range indices: bb134: 2696 %reg1645<def> = FsMOVAPSrr %reg1458<kill> ; srcLine 0 bb74: 2700 %reg1176<def> = FsMOVAPSrr %reg1645<kill> ; srcLine 0 2704 %reg1177<def> = FsMOVAPSrr %reg1646<kill> ; srcLine 0 *** u before d 2708 %reg1178<def> = FsMOVAPSrr %reg1647<kill> ; srcLine 0 *** u before d 2712 TEST64rr %reg1173, %reg1173, %EFLAGS&...

On Thursday 02 October 2008 12:42, David Greene wrote: > But let's say you _could_ write such a pattern (because I can). The input > DAG looks like this: > > 0x391a220: <multiple use> > 0x391c970: v2f64 = scalar_to_vector 0x391a220 srcLineNum= 10 > 0x391ac10: <multiple use> > 0x391c8b0: v2f64 = scalar_to_vector 0x391ac10 srcLineNum= 10 > 0x3927b10: <multiple use> > 0x3923100: v2f64 = vector_shuffle 0x391c970, 0x391c8b0, > 0x3927b10<0,2> srcLineNum= 10 > >...

...>> care if a live interval overlaps live ranges defined by an >> implicit_def. > > It's a bug because the coalerscer does illegal coaescing. > > Our last episode left us here: > > bb134: > 2696 %reg1645<def> = FsMOVAPSrr %reg1458<kill> ; srcLine 0 > > bb74: > 2700 %reg1176<def> = FsMOVAPSrr %reg1645<kill> ; srcLine 0 > [deleted copy] > 2708 %reg1178<def> = FsMOVAPSrr %reg1647<kill> ; srcLine > 0 *** u > before d > 2712 TEST64rr %reg1173, %reg1173, %EFLAGS<imp-def&...

...local variables. I've patched that here and hope to send it upstream once I get approval. But let's say you _could_ write such a pattern (because I can). The input DAG looks like this: 0x391a220: <multiple use> 0x391c970: v2f64 = scalar_to_vector 0x391a220 srcLineNum= 10 0x391ac10: <multiple use> 0x391c8b0: v2f64 = scalar_to_vector 0x391ac10 srcLineNum= 10 0x3927b10: <multiple use> 0x3923100: v2f64 = vector_shuffle 0x391c970, 0x391c8b0, 0x3927b10<0,2> srcLineNum= 10 The code that gets produced looks...

...October 2008 12:42, David Greene wrote: > >> But let's say you _could_ write such a pattern (because I can). >> The input >> DAG looks like this: >> >> 0x391a220: <multiple use> >> 0x391c970: v2f64 = scalar_to_vector 0x391a220 srcLineNum= 10 >> 0x391ac10: <multiple use> >> 0x391c8b0: v2f64 = scalar_to_vector 0x391ac10 srcLineNum= 10 >> 0x3927b10: <multiple use> >> 0x3923100: v2f64 = vector_shuffle 0x391c970, 0x391c8b0, >> 0x3927b10<0,2> srcLineNu...

I'm debugging some X86 patterns and I want to understand the debug dumps from isel better. Here's some example output: 0x391bc40: i64,ch = load 0x3922c50, 0x391b8d0, 0x38dc530 <0x39053e0:0> <sext i32> alignment=4 srcLineNum= 10 0x3922c50: <multiple use> 0x391bc40: <multiple use> 0x3856ab0: <multiple use> 0x3914520: i64 = shl 0x391bc40, 0x3856ab0 srcLineNum= 10 0x38569b0: <multiple use> 0x391bdf0: i64 = add 0x3914520, 0x38569b0 srcLineNum= 10...

...39;t > > attached anywhere and how can I get rid of it? > > Don't do undefined behavior? :) I don't think it's undefined behavior. Right before instcombine, we have this: %r60 = load <2 x i64>* %"$LCS_1", align 16 ; <<2 x i64>> [#uses=2] ; srcLine 41 %r61 = extractelement <2 x i64> %r60, i32 0 ; <i64> [#uses=1] ; srcLine 41 %r62 = getelementptr <2 x double>* null, i32 0, i64 %r61 ; <double*> [#uses=1] ; srcLine 41 %r63 = load double* %r62 ; <double> [#uses=1] ; srcLine 41 So we're loading a vector...

...d how can I get rid of it? > > > > Don't do undefined behavior? :) > > I don't think it's undefined behavior. Right before instcombine, we have > this: > > %r60 = load <2 x i64>* %"$LCS_1", align 16 ; <<2 x i64>> [#uses=2] ; > srcLine 41 > %r61 = extractelement <2 x i64> %r60, i32 0 ; <i64> [#uses=1] ; srcLine > 41 %r62 = getelementptr <2 x double>* null, i32 0, i64 %r61 ; <double*> > [#uses=1] ; srcLine 41 > %r63 = load double* %r62 ; <double> [#uses=1] ; srcLine 41 > > So...

On Fri, 4 Apr 2008, David Greene wrote: > I am confused by this bit of code in instcombine: > > 09789 if (GetElementPtrInst *GEPI = dyn_cast<GetElementPtrInst>(Op)) { > 09790 const Value *GEPI0 = GEPI->getOperand(0); > 09791 // TODO: Consider a target hook for valid address spaces for this > xform. > 09792 if (isa<ConstantPointerNull>(GEPI0)

I am confused by this bit of code in instcombine: 09789 if (GetElementPtrInst *GEPI = dyn_cast<GetElementPtrInst>(Op)) { 09790 const Value *GEPI0 = GEPI->getOperand(0); 09791 // TODO: Consider a target hook for valid address spaces for this xform. 09792 if (isa<ConstantPointerNull>(GEPI0) && 09793

...ce:]]", chunkprefix)) + chunkprefix = shQuote(chunkprefix, type = "cmd") cat("\\includegraphics{", chunkprefix, "}\n", sep = "", file = object$output) linesout[thisline + 1L] <- srcline Thanks! Regards, Yihui -- Yihui Xie <xieyihui at gmail.com> Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA

On Friday 30 January 2009 15:10, David Greene wrote: > This still looks correct. The coalescer then says: > > 4360 %reg1177<def> = FsMOVAPSrr %reg1176<kill> ; srcLine 0 > Inspecting %reg1176,0 = [2702,4362:0) 0 at 2702-(4362) and %reg1177,0 = > [2700,3712:0)[3768,3878:0)[4362,4372:0) 0 at 4362-(3878): > Joined. Result = %reg1177,0 = [2700,4372:0) 0 at 2702-(4362) > > Eh? How can it coalesce these two? Doesn't %reg1176:[2702,4362:0) o...

...d to speed up Dhrystone on ARM Cortex-A8 by optimizing the > memcpy intrinsic. I used the Neon load multiple instruction to move up > to 48 bytes at a time . Over 15 scalar instructions collapsed down > into these 2 Neon instructions. > > fldmiad r3, {d0, d1, d2, d3, d4, d5} @ SrcLine dhrystone.c 359 > fstmiad r1, {d0, d1, d2, d3, d4, d5} > > It seems like this should be faster. But I did not see any > appreciable speedup. > > I think the patch is correct. The code runs fine. > > I have attached my patch for "lib/Target/ARM/ARMISelLowering.cp...

I tried to speed up Dhrystone on ARM Cortex-A8 by optimizing the memcpy intrinsic. I used the Neon load multiple instruction to move up to 48 bytes at a time . Over 15 scalar instructions collapsed down into these 2 Neon instructions. fldmiad r3, {d0, d1, d2, d3, d4, d5} @ SrcLine dhrystone.c 359 fstmiad r1, {d0, d1, d2, d3, d4, d5} It seems like this should be faster. But I did not see any appreciable speedup. I think the patch is correct. The code runs fine. I have attached my patch for "lib/Target/ARM/ARMISelLowering.cpp" to this email. Does this look...

...text included in the text of the .Rnw file: $ svn diff Index: src/library/utils/R/Sweave.R =================================================================== --- src/library/utils/R/Sweave.R (revision 53846) +++ src/library/utils/R/Sweave.R (working copy) @@ -20,6 +20,16 @@ # We don't need srclines for code, but we do need it for text, and it's easiest # to just keep it for everything. +SweaveGetDriver <- function(file){ + txt <- readLines(file) + line <- grep( "\\SweaveDriver", txt, value = TRUE ) + if( length(line) ){ + txt <- sub( "^.*\\S...