similar to: [LLVMdev] Profiling questions

We are working on a backend for an ILP architecture, and at some point we would like to do some sort of region scheduling. To support region formation, we need to collect profiling information. I took a look at the bitcode interpreter, and it is fairly trivial to make it collect profiling data Our target is an ASIP for embedded applications, so it would typically be simulated during software

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

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

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

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

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?

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