similar to: [LLVMdev] LLVM performance test

Hi, I have two related questions: Are there LLVM developers on this list that are interested in improving LLVM performance? I have examples in which LLVM is slower than gcc (e.g., STM linked list microbenchmark, 1.8 (gcc) vs. 1.3 (llvm), more is better). I've never done compiler performance tuning, so I don't know how much effort is required. Second question: does anyone keep track

Hi Torvald, On Oct 27, 2010, at 8:01, Torvald Riegel wrote: > On Tuesday 26 October 2010 14:33:02 Duncan Sands wrote: >>> transaction properties (eg, virtually atomic + isolated execution) for >>> ordinary program code. Thus, to make incrementing a counter thread-safe, >>> you could say __transaction { counter++; } and the compiler would >>> transform this

On Tuesday 26 October 2010 14:33:02 Duncan Sands wrote: > > transaction properties (eg, virtually atomic + isolated execution) for > > ordinary program code. Thus, to make incrementing a counter thread-safe, > > you could say __transaction { counter++; } and the compiler would > > transform this code so that it uses a TM library, which in turn does > > concurrency

First of all, I'd like to thank the entire LLVM team for this opportunity. Torvald, google only displays the abstract on the results page, but I do know about Tanger and it was mentioned in both the proposal and the comments that followed, I'll write an email to you later with that info in a bit, and I do intend to use as much available infrastructure as possible, and tanger/tinystm are

Hi Anton, You're already a part of the llvm development team by participating actively on the llvm development list :) If you wish we can put you on: http://llvm.cs.uiuc.edu/Developers.html Great to have you on the team, welcome! We (Jeff, Morten, Paolo, the rest of the team and I) are looking forward to cooperate with you and to push win32 and mingw versions even further to stable and

On Tuesday 22 April 2008, Chris Lattner wrote: > [llvmir] "Software Transactional Memory (STM) support in LLVM" by > Luis Felipe Strano Hi, I'd like to know more about the directions for the STM project. Somewhat contrary to what the project's abstract states, there are open C/C++ based implementations for compiler support for memory transactions. Besides some

Torvald, This is nice work. Do you have a set of applications or benchmarks that you have transactionalized at the source level? If so, have you reported performance numbers for them somewhere? Thanks, --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.org On Aug 19, 2007, at 3:22 PM, Torvald Riegel wrote: > I would like to announce the availability of compiler support for >

How can a frontend tell LLVM to put a function argument on stack/register/etc? On Thu, Oct 4, 2012 at 5:08 PM, Anton Korobeynikov <asl at math.spbu.ru> wrote: >> Ah, got it. >> Sounds like we might need to introduce CC_X86_Win32_MSVC_ThisCall then?.. > No, we should not. It should be properly expanded in frontend. > > -- > With best regards, Anton Korobeynikov >

I tried to ask for 32 and that didn't seem to help. MallocInst also seemed to ignore the 16 byte directive. For now, I'm just issuing all my loads as unaligned and that's working ok. Thanks, Chuck. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng Sent: Monday, October 01, 2007 10:35 AM To: asl at

I would like to announce the availability of compiler support for generation of transactional code in LLVM IR. Our tool is called Tanger and it is an LLVM pass. You can download Tanger at: http://tinystm.org Transactional memory (TM) is viewed by a lot of people to be an important tool for enabling parallelism in a wide area of applications, and especially for developers that are not skilled

Chuck, > It is dying trying to store a our working vector into one of the LLVM > vectors created on the stack. Despite the align-16 directive on the > alloca instruction, it is not always aligning to a 16-byte boundary. The stack is not necessary 16 bytes aligned on linux/windows. The vector is really sotred aligned relative to %esp, but %esp value is not good. This is known problem

Hello, Bill. > Has anyone gotten the latest/greatest sources from the LLVM-GCC open > source server lately? No. It's still at rev 319 (as of 29.04). -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Bill, > When I try to compile on Darwin now, I get this: Could you please provide LLVM bytecode, where bug is reproducible with llc? -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Hello, Rafael > With this patch I was able to bootstrap gcc in linux x86-64 with > shared libraries enabled :-) Awesome! But... -ENOPATCH :( -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

> Ah, got it. > Sounds like we might need to introduce CC_X86_Win32_MSVC_ThisCall then?.. No, we should not. It should be properly expanded in frontend. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

2013/3/28 Anton Korobeynikov <asl at math.spbu.ru>: >> How can having an MSVC compatible compiler be to the detriment of clang and >> llvm? No one is trying to break mingw here, merely add support for something > Just to make stuff clear: I just wanted proper naming which will be > non-confusing. Right now we have: > - isTargetWindows() which really means

Nothing... I'll show you all the info related to: The intrinsic: def int_soru_sre : Intrinsic<[llvm_void_ty, llvm_i32_ty], [IntrWriteMem]>; The lower instruction (in MIPS): class SORUI<bits<6> op, dag outs, dag ins, string asmstr, list<dag> pattern, InstrItinClass itin>: FI<op, outs, ins, asmstr, pattern, itin> { let isBarrier = 1; // or call,

Hello, Bill > It may be my lack of understanding, but it appears that having -- > enable-eh set during compilation of llvm-gcc is causing extra files > to be compiled. Oh, no. They are always compiled. > They do. However, it doesn't seem to stop it from failing during > compilation of unwind-dw2.c for libgcc -- it has > "__builtin_eh_return" in it. During

Hello, Daniel. > glibc < 2.4 don't reliably keep stack at 16 bytes through some calls > (qsort, etc), but otherwise, it stays 16 byte aligned. Interesting, but why in this case stuff like 'force_align_arg_pointer' required? -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Hi Thanks for the info, it led to the source of the error I was having. I was using llvm-gcc binaries (built with mingw I guess) to compile a .c file that is my language runtime, llvm-link'ing that with my frontend's .ll, and using an vcpp-built lli to run the resulting bytecode. This caused the special case in X86RegisterInfo::emitPrologue for "main" to try to align the stack