similar to: [LLVMdev] Size and performance figures for LLVM?

On May 12, 2008, at 2:59 AM, Pertti Kellomäki wrote: > 2) What is the relative performance of code generated by LLVM > and gcc respectively? See llvm.org/nightlytest Many testers run various benchmarks and produces comparison numbers daily. > I am not looking for exact answers, rough ballpark figures > are quite sufficient. - Devang

Am Montag, den 12.05.2008, 09:08 -0700 schrieb Devang Patel: > On May 12, 2008, at 2:59 AM, Pertti Kellomäki wrote: > > > 2) What is the relative performance of code generated by LLVM > > and gcc respectively? > > See llvm.org/nightlytest Which does not compare GCC vs. LLVM. (I haven't seen this announced as the nightly tester's purpose either.) > Many

> See llvm.org/nightlytest Many testers run various benchmarks > and produces comparison numbers daily. Can I trust those numbers? For example, right now I'm looking at http://llvm.org/nightlytest/machine.php?machine=230. "CVS checkout time" might be wrong, as LLVM is now in SVN. This column also jitters heavily. However, it's not really important. "Configure

On May 12, 2008, at 10:19 AM, Joachim Durchholz wrote: > > Am Montag, den 12.05.2008, 09:08 -0700 schrieb Devang Patel: >> On May 12, 2008, at 2:59 AM, Pertti Kellomäki wrote: >> >>> 2) What is the relative performance of code generated by LLVM >>> and gcc respectively? >> >> See llvm.org/nightlytest > > Which does not compare GCC vs. LLVM.

Am Montag, den 12.05.2008, 10:48 -0700 schrieb Chris Lattner: > On May 12, 2008, at 10:19 AM, Joachim Durchholz wrote: > > > > > Am Montag, den 12.05.2008, 09:08 -0700 schrieb Devang Patel: > >> On May 12, 2008, at 2:59 AM, Pertti Kellomäki wrote: > >> > >>> 2) What is the relative performance of code generated by LLVM > >>> and gcc

Hi Reid, I'll write a separate post about the intrinsics, but just a quick note about the CFLAGS issue. Reid Spencer kirjoitti: > On Thu, 2006-11-09 at 15:29 +0200, Pertti Kellomäki wrote: >> Another related thing is that even when I defined -emit-llvm in >> what I thought would be a global CFLAGS for all of newlib, it did >> not get propagated to all subdirectories.

This came up when trying to compile the Python bindings against llvm 1.7. File include/llvm/Transforms/Scalar.h declares llvm::createPREPass(), which does not seem to be implemented anywhere. Should I report this in llvmbugs? -- Pertti

On 15.10.2008, at 14.01, Pertti Kellomäki wrote: > Tatu Vaajalahti wrote: >> With this program llvm-gcc -O2 optimizes test2 away even though it's >> address is taken in program (gcc-4.2 does not, neither does llvm-gcc >> with -O or -O0): >> >> >> #include <stdio.h> >> >> static const char test1 = 'x'; >> static const char

Pertti Kellomäki wrote: > This came up when trying to compile the Python bindings > against llvm 1.7. File include/llvm/Transforms/Scalar.h > declares llvm::createPREPass(), which does not seem to > be implemented anywhere. Should I report this in llvmbugs? Just to clarify myself: this is an issue with the LLVM sources, not with the Python bindings. -- Pertti

Tatu Vaajalahti wrote: > On 15.10.2008, at 14.01, Pertti Kellomäki wrote: >> Seems to me that it is perfectly legitimate for the compiler to fold >> the two char constants together. > True, but note that it is the address of a variable that is used, not > the value. I don't have the C standard handy, but I would be somewhat surprised if the standard would explicitly

I am having a strange problem with loop unrolling. Attached is a small example that demonstrates what happens. There is a for-loop with a known trip count, and some control flow inside the loop. If the condition of the control flow only depends on the loop index and loop invariant variables, the loop is not unrolled. However, if the condition involves potentially loop variant variables, the loop

On Wed, 22 Nov 2006, [ISO-8859-1] Pertti Kellom�ki wrote: > Aside from stuff that depends on system headers, are there any other > dependencies on the host system? In other words, will llvm-gcc produce > exactly the same byte code for a given set of source files regardless of > where compilation takes place? This has obvious implications on Yes. Many aspects of the target compiler

Hi Adam, John is right, the TCE stuff would be useful for you. Our compiler targets a processor template that the designer can populate pretty freely. The compiler then reads the architecture description and creates an LLVM backend on the fly. Please don't hesitate to get in touch with us if you have questions. -- Pertti

Pertti Kellomäki schrieb: > Chris Lattner wrote: >> Many aspects of the target compiler can leak through. > > So if one wants to use the LLVM system as a cross compiler, one > has to configure llvm-gcc as a cross compiler? Fair enough, I guess. I hope the C backend is still meant to generate portable code though. Philipp

I managed to compile newlib with llvm-gcc yesterday. That is, the machine independent part is now basically done, and the syscall part contains no-op stubs provided by libgloss. I haven't tested the port yet, but since newlib has already been ported to many architectures, I would be pretty surprised if there were any major problems. A couple of things I noticed when configuring newlib for

Chris Lattner wrote: > Many aspects of the target compiler can leak through. So if one wants to use the LLVM system as a cross compiler, one has to configure llvm-gcc as a cross compiler? Fair enough, I guess. > One trivial example is: > > int X = sizeof(long); So I assume this also means that while getelementptr insulates llvm byte code from the details of target specific address

Hello gyus, I am working on a project, where we are trying to create a development environment for new ASIP processor design. Part of this project is a compiler generator, where we would like to generate C compiler from some instruction description. To keep it short, let's say, that in each instruction's semantics is described by some C code. What I would like to do is to compile this

Hi Pertti, The boost Python are not (yet) part of LLVM so I suppose it would make most sense to try to makes fixes/changes so they would work for 1.7 and then try to get them into LLVM CVS. It would be good in such a case to ask the author of the bindings again if he would allow this, because basicaly I think he has to agree to the LLVM lincense. cheers, Eric On Apr 20, 2006, at 5:08

I am involved in a project where one of the aims is to study the effects of different parallelization strategies on efficiency, power consumption etc. The idea is to do automated design space exploration by varying some parameters (e.g. number of tasks) and measuring their effect. Since we are already using LLVM for other purposes, we thought about using LLVM for analysis and then OpenMP for

On Thu, 2008-03-27 at 21:39 +0200, Pertti Kellomäki wrote: > Except that some aspects of the host platform leak through > to .bc files. This may or may not be a problem. A question about this occurred to me last night. BitC has only one machine-dependent type: word. The current runtime.h file typedef's this in a machine-dependent way, but all of the C code emitted by our current back