similar to: [LLVMdev] Profiling with lli

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

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

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

I gave a short presentation on LLVM for a couple of people here, and they had questions I could not immediately answer. The questions are rather obvious, so I'm hoping that someone has already found out the answers. So here we go: 1) What is the relative size of LLVM bitcode files and the corresponding native binaries? Are there significant differences between targets (e.g. x86, ARM,

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

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

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

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

The open projects page at <http://llvm.org/OpenProjects.html> lists superblock formation as a possible idea for profile-guided transformations. Is anyone working on formation of regions consisting of multiple basic blocks? I don't recall any posts on llvmdev to that effect. It would be quite useful to have a general facility for grouping basic blocks within a function, as that could be

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

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

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

Pertti, On Feb 13, 2007, at 7:34 PM, Pertti Kellomäki wrote: > Dietmar Ebner wrote: >> most of the work seems to be done in an architecture dependent, >> very low- >> level IR. are there any efforts to generalize architecture >> independent portions >> of the code. >> any comments on this are very appreciated. > > We are in a similar

I looked at the profiling support in LLVM, and it seems that all the bits needed for profile guided transformations are there. We are using LLVM as a cross compiler, and the target is simulation only at the moment. Would it be possible to use the native llvm installation for profiling? That is, compile the application and run it on the host, collecting profile data. Then use the profile to guide

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

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

On Mon, 2008-05-19 at 20:40 +0300, Pertti Kellomäki wrote: > The only hitch is that in the MCU world people expect to be > able to write interrupt handlers and the like in C... Most of the support that I have seen for this in other compilers amounts to custom calling conventions and preambles. Are you thinking of more than this?