search for: probata

On Mon, Mar 2, 2009 at 4:58 PM, Jonathan Turner <probata at hotmail.com> wrote: > The crux of the example still seems intact. Have you tried putting something non-trivial (like asm("nop;");) where you'd put the code that runs on the timeout? -Eli

On Mon, Mar 2, 2009 at 11:38 AM, Jonathan Turner <probata at hotmail.com> wrote: > With gcc -O3 4.2 and 4.4 we match 1.0s.   The LLVM, after running it through > opt -std-compile-opts, is around 1.7s. 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 differ...

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'...

I was playing around in x86 assembly the other day, looking at ways to optimize my cooperative multitasking system. 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:

> You're misreading the asm... nothing is touching memory. (BTW, "leal > -1(%eax), %eax" isn't a memory operation; it's just subtracting one > from %eax.) You might want to try reading the LLVM IR (which you can > generate with llvm-gcc -S -emit-llvm); it tends to be easier to read. I tried that, but I'm still learning LLVM. Seeing indvar, phi nodes, tail

> 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

Greetings, I seem to be butting up against what may be a Vista-related issue for mingw-based compilation. I did some googling earlier today and found these steps: http://blogs.tedneward.com/2008/02/24/Building+LLVM+On+Windows+Using+MinGW32.aspx, which I followed. But try as I did, I couldn't seem to get past the "tools" section of the compilation. It seemed to always have

Recently I've been working on putting a little language together using the llvm toolset. I think I've wrapped my head around some of the beginner bits (and a big "thank you" for the kaleidoscope tutorial). What I'd like to do now is to take my Module* and output either a C file for native compilation, or just directly output a native binary. I saw that llc can output C

> Both of these issues are fixed. It will be regenerated tonight. > A lot of this stuff is automated and occasionally we have snags in the > system. I appreciate you bringing it to my attention. One more that might also be regenerated(?), but I noticed today that the live demo at http://llvm.org/demo/index.cgi now returns errors if you check the "Show LLVM C++ API code" box.

Saw this mentioned on Lambda, and thought it was worth pointing out (though I'm betting most of you are Lambda readers). Looks like it's a new approach to mapping out optimizations and picking the best ordering/grouping. http://www.cse.ucsd.edu/~rtate/publications/eqsat/ Just watched the video and am settling down to read the paper, and it looks interesting so far. Anyone more

Just thought I'd mention this to keep other people from stubbing their toes on it... Using llvm-gcc/llvm-g++ and -emit-llvm, you need to make sure to pass -S as well, like so: ./llvm-g++ -S -emit-llvm hello.cpp not: /llvm-g++ -emit-llvm hello.cpp I'm sure that's old news to most of the people on the list, but I thought it couldn't hurt to mention it in case other people happen