search for: loopto

...crux of the example still seems intact. From LLVM SVN, converted to asm via llc: .text .align 4,0x90 .globl _main _main: subl $12, %esp movl $1999, %eax xorl %ecx, %ecx movl $1999, %edx .align 4,0x90 LBB1_1: ## loopto cmpl $1, %eax leal -1(%eax), %eax cmove %edx, %eax incl %ecx cmpl $999999999, %ecx jne LBB1_1 ## loopto LBB1_2: ## bb1 movl %eax, 4(%esp) movl $LC, (%esp) call _printf xorl %eax, %eax...

...Currently, it uses a 'timeout' counter that is decremented each time through a loop, letting me stop the loop and go to the next cooperative thread if the loop runs a little long. The asm has two overlapping loops: --- _main: mov ecx, 1000000000 timeoutloop: mov edx, 2000 loopto: dec edx jz timeoutloop dec ecx jnz loopto mov eax, 0 ret --- Which takes 1.0s on my machine. To compare, I wanted to see what LLVM performance was like and if a similar technique would yield good performance. I cooked up this test in C: --- #incl...

Hello, I'm back :) This patch fixes pr3707. Regards -Jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: pr3707.patch Type: application/octet-stream Size: 3247 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091010/301a2761/attachment.obj>

On Oct 10, 2009, at 7:48 AM, Jakub Staszak wrote: > Hello, > > I'm back :) Great! > This patch fixes pr3707. Can you explain a little more what this does? What is the intuition behind disabling this optimization? -Chris

#Hello, #I have three data frames, X,Y and Z with two columns each and different numbers of rows. # creation of data frame X X.alleles <- c(1,5,6,7,8) X.Freq <- c(0.35, 0.15, 0.05 , 0.10, 0.35) Loc1 <- cbind( X.alleles,X.Freq) X <- data.frame(Loc1) #creation of data frame Y Y.alleles <- c(1,4,6,8) Y.Freq <- c(0.35, 0.35, 0.10, 0.20 )

On Mon, Mar 2, 2009 at 2:45 PM, Jonathan Turner <probata at hotmail.com> wrote: > For which version of gcc?  I should mention I'm on OS X and using the LLVM > SVN. gcc 4.3. It's also possible this is processor-sensitive. >> First, try looking at the generated code... the code LLVM generates is >> probably not what you're expecting. I'm getting the

> Date: Mon, 2 Mar 2009 13:41:45 -0800 > From: eli.friedman at gmail.com > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Tight overlapping loops and performance > > Hmm, on my computer, I get around 2.5 seconds with both gcc -O3 and > llvm-gcc -O3 (using llvm-gcc from svn). Not sure what you're doing > differently; I wouldn't be surprised if it's

...Should I be looking at any particular optimization passes that aren't in > -std-compile-opts to match the gcc speeds? First, try looking at the generated code... the code LLVM generates is probably not what you're expecting. I'm getting the following for the main loop: .LBB1_1: # loopto cmpl $1, %eax leal -1(%eax), %eax cmove %edx, %eax incl %ecx cmpl $999999999, %ecx jne .LBB1_1 # loopto LLVM is optimizing your oddly nested loops into a single loop which does some extra computation to keep track of the timeout variable. Since you'd normally be doing something non-trivi...