similar to: [LLVMdev] promoting small integers to 32 bits

Based on cmake/modules/LLVMLibDeps.cmake, I produced a graphviz dot file and then manually removed components and edges until the graph was small enough to be presentable. I don't know if I can actually use LLVM due to its humongousness, but I hope the graph will be helpful to others attempting to comprehend LLVM. PNG attached; dot file follows. digraph G { ipo

I tried building LLVM 2.1 with no real target CPU backends enabled, just the C backend, by hacking the configure script slightly: --- /home/foad/llvm/llvm-2.1/configure 2007-09-17 22:37:52.000000000 +0100 +++ configure 2007-12-13 10:29:41.000000000 +0000 @@ -4762,7 +4762,7 @@ done ;; esac -TARGETS_TO_BUILD="CBackend MSIL $TARGETS_TO_BUILD"

Hi there, I'm having a hard time with promoting operands from i1 to i32 in my backend... I have to register classes, VTs are i1 and i32. The i1 registers are only for predication and conditional jumps, so I want to use them with brcond, setcc. There are no instructions to directly load a value in an i1 register or to copy between i1 and i32, so I need the DAG Legalizing Pass to not generate

> > Just in case it gets lost in my longer reply, I want to emphasize that if > these will be used to simplify the in-tree backends and those backend > maintainers are on board, then I am *totally* in favor of this going into > the tree. My concerns are heavily based on the fact that as proposed, none > of that seems likely to happen. > > > Framing the problem

Hi all! I gave a shot at compiling core llvm with a Solaris 9 machine. The compiler is FSF gcc 3.4.6. I am building trunk in the release version. So far I did not run tests (no dejagnu installed). Here are my findings: 0) Configuring. I had to suppress the solaris tools by: env AR=/opt/gnu/bin/ar NM=/opt/gnu/bin/nm RANLIB=/opt/gnu/bin/ranlib STRIP=/opt/gnu/bin/strip ../llvm/configure

Hey there, Searching via the web is not producing answers.... So I thought I would ask the gods of llvm. :-) I'd like to experiment with the llc in conjunction with msil. but I am running into this error: llc-mp-2.9 test.ll -march=msil /opt/local/libexec/llvm-2.9/bin/llc: error: invalid target 'msil'. the version string is: llc-mp-2.9 --version Low Level Virtual Machine

Dear Rudiger, Rüdiger Klaehn wrote: > Hello all. > > is it possible to use LLVM to optimize existing .NET assemblies? > It's in theory possible. LLVM+VMKit already does it for Java classes. > Basically doing the following: > > - read in MSIL and convert into LLVM internal representation > - perform global optimizations on LLVM internal representation > - write

Per subject, this patch adding an additional pass to handle vector operations; the idea is that this allows removing the code from LegalizeDAG that handles illegal types, which should be a significant simplification. There are still some issues with this patch, but does the approach look sane? -Eli -------------- next part -------------- Index: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp

Hello, > As for the state of the MSIL backend of LLVM, I don't think it's for > production use yet. Assemblies have lots of information in them and > maintaining them during the MSIL -> LLVM -> MSIL translations should be > the hard part. This should be pretty hard. MSIL is definitely much more high level than LLVM, that's why significant portion of information will

Hello all. is it possible to use LLVM to optimize existing .NET assemblies? Basically doing the following: - read in MSIL and convert into LLVM internal representation - perform global optimizations on LLVM internal representation - write out optimized MSIL using the existing LLVM backend I presume that the capability to convert MSIL into LLVM internal representation exists somewhere in VMKit.

Hello, Jeff. > I'm confused. A MSIL front end I can understand, but a back end? How > will it be used? The GCC-based front ends that come with LLVM generate > bytecodes that have dependencies on the GCC runtime, which is not going > to be present in a .NET environment. Well. It's LLVM-to-MSIL translator. So, if the source use some unsupported code... The same situation

Hi Artur, Artur Pietrek wrote: > Hello, > > I work in Kalray (Montbonnot, France) and I'm PhD student at Universite > Joseph Fourier in Grenoble. > We want to use LLVM framework for MSIL code generation, which is part of > my thesis. > Currently I'm still reading LLVM's documentation and I've started > completing the MSIL backend for running on Mono.

Hello, I work in Kalray (Montbonnot, France) and I'm PhD student at Universite Joseph Fourier in Grenoble. We want to use LLVM framework for MSIL code generation, which is part of my thesis. Currently I'm still reading LLVM's documentation and I've started completing the MSIL backend for running on Mono. Things that need to be fixed include pointers initialization, call to

Chris Lattner wrote: > On Thu, 22 Mar 2007, Jeff Cohen wrote: >> I'm confused. A MSIL front end I can understand, but a back end? How >> will it be used? The GCC-based front ends that come with LLVM generate >> bytecodes that have dependencies on the GCC runtime, which is not going >> to be present in a .NET environment. > > Who said the input has to come

Chris Lattner wrote: > x. Roman Samoilov contributed a new MSIL backend to LLVM. llc - > march=msil will now turn LLVM into MSIL (".net") bytecode. This is > still fairly early development with a number of limitations. > This ought not be advertised to the world. It is not useful for any purpose. Not only can it not do virtual method calls, as I previously

On Sat, May 16, 2009 at 5:09 PM, Anton Korobeynikov <anton at korobeynikov.info > wrote: > Hello, > > > As for the state of the MSIL backend of LLVM, I don't think it's for > > production use yet. Assemblies have lots of information in them and > > maintaining them during the MSIL -> LLVM -> MSIL translations should be > > the hard part. > This

Dear LLVM, I'm trying to understand why the attached IR code works for x86_64 target and fails for nvptx64, because of unimplemented expand during the target lowering. Any ideas? Just change the target triple to x86_64-unknown-unknown, and the same IR code could we successfully codegen-ed for x86_64. Thanks, - Dima. dmikushin at dmikushin-desktop:~/Desktop$ gdb ~/sandbox/bin/llc GNU gdb

Both backends are important but I find it more important the MSIL backend, for now. It's a shame that nobody is picking up the MSIL backend; it would be useful another backend that is machine-independent and that has support for several tools. -----Mensagem original----- De: llvmdev-bounces at cs.uiuc.edu em nome de Bruno Cardoso Lopes Enviada: qua 05-11-2008 19:47 Para: LLVM Developers

Hi, Has some one committed these patches into CVS? Paolo, thanks for the patches. In the near future I'll try to compile them. I've installed STLport 6.4.2 with vc6. Henrik --- Got Freedom? Software Freedom Day 2004 - 28th of August http://www.softwarefreedomday.org/ --- >From: Paolo Invernizzi <arathorn at fastwebnet.it> >Reply-To: LLVM Developers Mailing List

On Thu, 22 Mar 2007, Jeff Cohen wrote: > The problem is worse than I thought. > > MSIL, and .NET in general, defines a specific object model. This object > model is explicitly part of MSIL semantics. LLVM is at a lower level; > it does not have an object model. To do a virtual call, LLVM > instructions must be generated to load a function pointer from a vtable Unlike Java,