search for: wopts

Hi, Arvind Sudarsanam: I know some of Open64. Above all, Open64 is designed for a high performance compiler. It is now supported by AMD, HP, ICT Chinese Academy of Science, etc. and has been ported to X86, Itanium, Loongson CPU etc. And to your questions 1, Open64 already have some main optimization phases, Inline for aggressive inline opt. LNO for loop opt, WOPT for machine independent opt(

Hi, I have been working towards developing compiler optimization tools targeting multi core processors while using LLVM IR as the starting point and building on top of the analysis and optimization passes available in the llvm source. Recently, I looked into Open64 and its intermediate representation WHIRL. Documentation for developers to use Open64 seems to be inadequate (when compared to LLVM

On Aug 24, 2007, at 1:52 PM, Holger Schurig wrote: > Is llvmc meant for compilation? > I'm not sure what the status of llvmc is (is anyone working on it?), but I don't believe it was ready for real use or was finished. If you would like to work on it, patches are welcomed! Thanks, Tanya > $ llvmc -c a.c -o a.o > /usr/src/llvm/dist/etc/llvm/c:55: Error: Expecting output

Is llvmc meant for compilation? $ llvmc -c a.c -o a.o /usr/src/llvm/dist/etc/llvm/c:55: Error: Expecting output type value /usr/src/llvm/dist/etc/llvm/c had 1 errors. Terminating. The offending line contains: optimizer.output = bytecode which doesn't seem to be understood by llvmc. If I uncomment this line, I get another error message: $ llvmc -c a.c -o a.o llvmc: Can't find program

Here is the bulk of the sanitizing. My residual doubts center around the question whether we still do/want to support (un)compressed *byte*code in 2.0/2.1. I need a definitive word on this to proceed. My understanding is that bytecode is already gone, but there are still some functions/enums that really deal with *byte*code (instead of *bit*code). I did not touch those areas, so the attached