similar to: [LLVMdev] tablegen problem with LLVM 2.5 cross build

On Mon, Jul 20, 2009 at 4:15 AM, Carter Cheng<carter_cheng at yahoo.com> wrote: > This is probably another very basic question- but is there a simple method for cross compiling LLVM for another platform? If you already have a cross-compiling environment set up, it shouldn't be too hard; for LLVM and llvm-gcc, you should be able to pass in --host=mytarget to configure, and if

Yes. But it is not really being used by most (any?) targets because post-RA scheduling is disabled by default. Also, the existing model is very limited in what types of micro-architectures can be described. I've been extending it to enable scheduling of multi-issue targets, targets with overlapping FU usage, and targets that use and define registers in multiple pipeline stages. See

Actually after some digging I managed to answer these questions for myself. I am guessing that this information is used by the Schedule* classes in CodeGen. --- On Mon, 8/17/09, Carter Cheng <carter_cheng at yahoo.com> wrote: > From: Carter Cheng <carter_cheng at yahoo.com> > Subject: [LLVMdev] ARMSchedule.td MipsSchedule.td etc. > To: llvmdev at cs.uiuc.edu > Date:

Hello, (cc:llvmdev Keeping on the list to get more eyes on the problem and for archival purposes). Configure will be re-run, yes. LLVM includes some tools which need to be built for the host, even when cross compiling (e.g., tblgen). In a cross-build, these are built in the BuiltTools directory and that's where you're seeing configure being re-run. >From the below snippet it appears

On Sep 1, 2010, at 4:35 AM, Amaury Pouly wrote: > Hello, > I was fiddling with TableGen (for a use that has nothing to do with a compiler but it's doesn't matter) and TableGen triggers an assertion failure on this code (I reduced the case to the minimum, it's a parsing bug): David, can you take a look? This is related to your lisp interpreter :) -Chris > > class

I apologize if this has been asked before but which classes utilize the information in these files? I am asking since I am trying to extend the MIPS backend to 64bit among other things. Thanks in advance, Carter.

While I'm at it, I noticed a behaviour which is not exactly related but similar. To put it simply, you can 't do T.V.W, you need to do !cast<Bla>(T.V).W Example: class Bla<string t> { string blu = t; } class Bli<Bla t> { Bla bla = t; } def a : Bli<Bla<"">>; def b : Bla<!cast<Bla>(a.bla).blu>; // works def b :

Hello, I was fiddling with TableGen (for a use that has nothing to do with a compiler but it's doesn't matter) and TableGen triggers an assertion failure on this code (I reduced the case to the minimum, it's a parsing bug): class Bli<string _t> { string t = _t; } class Bla<list<Bli> _bli> : Bli<!car(_bli).t> { } #0 0x00007ffff6ebda75 in *__GI_raise

Hello I am new to LLVM and would like to cross-compile LLVM 2.9 on x86 (Ubuntu) to ARM using Code Sourcery LIte toolchain for ARM EABI (2011.03-41). This is the command I used to configure: ./configure --build=i686-pc-linux-gnu --host=arm-none-linux-gnueabi --target=arm-none-linux-gnueabi followed by: make -C llvm.2.9 ENABLE_OPTIMIZED=0 I encountered the following errors: configure:error:

Hi, I'm using a Mac build of my clang/LLVM based tool chain ELLCC (http://ellcc.org) and attempting to cross build itself for ARM/Linux. I get the following error: llvm[3]: (build tools): Linking Release+Asserts executable llvm-tblgen (whithout symbols) ld: unknown option: --version-script=/Users/rich/ellcc/llvm/autoconf/ExportMap.map clang: error: linker command failed with exit code 1

This is probably another very basic question- but is there a simple method for cross compiling LLVM for another platform? Thanks in advance.

On Sun, Aug 2, 2009 at 6:09 PM, Carter Cheng<carter_cheng at yahoo.com> wrote: > I just looked over your diff and it would seem to me that additional changes would be needed to be done to some of the LLVM-IR -> DAG stuff to make things fully functional (this could be a bit of supposition on my part since I do not fully understand all of the code). Code generation actually was

Hi Carter, Carter Cheng wrote: > Hello, > > This is probably a bit of a beginner's question but I am new to LLVM > I have been examining the possibility of constructing something similar to the JnJVM for a language which supports dynamic class loading. The problem I am having is determining how the JIT system allows for dynamic loading of functions into the JIT. The paper

Thanks both. I looked over the getelementptr and bitcast documentation but I am still a bit confused by one point. lets say i have something like this. union { long Int; double float; long* IntRef; } Since pointer sizes are platform dependent if I am trying to use the union in question with an extern C function is it possible to make write the single definition in a platform independent way?

Hi, Does anyone have experience with doing Canadian cross-builds of LLVM compiler? I need some help here... I'm a new with LLVM, so please don't be too harsh on me. I am building LLVM cross-compiler (and as I mentioned I'm doing it via canadian cross-build): Build platform = Linux, Host platform = Windows Target platform = Linux I'm using mingw32 compiler toolchain to

I just looked over your diff and it would seem to me that additional changes would be needed to be done to some of the LLVM-IR -> DAG stuff to make things fully functional (this could be a bit of supposition on my part since I do not fully understand all of the code). --- On Sun, 8/2/09, Andrew Lenharth <andrewl at lenharth.org> wrote: > From: Andrew Lenharth <andrewl at

Hello, Ekaterina. FYI, my configure has '--host=i686-pc-mingw32' w/o any additional variables. and then the build host (ppc fedora 12) has toolchain 'i686-pc-mingw32-*'. It could build everything successfully, but I have not built it for a few months :p 2010/11/30 Ekaterina Sanina <ekaterina.sanina at gmail.com>: > cross-compile-build-tools: >         $(Verb) if [ !

On Tue, Jun 30, 2009 at 12:16 AM, Carter Cheng<carter_cheng at yahoo.com> wrote: > Since pointer sizes are platform dependent if I am trying to use the union in question with an extern C function is it possible to make write the single definition in a platform independent way? Not really; there's some discussion of that in the thread starting at

Eli Friedman wrote: > On Tue, Jun 30, 2009 at 12:16 AM, Carter Cheng<carter_cheng at yahoo.com> wrote: > >> Since pointer sizes are platform dependent if I am trying to use the union in question with an extern C function is it possible to make write the single definition in a platform independent way? >> > > Not really; there's some discussion of that in

On Mon, Jul 27, 2009 at 8:56 AM, Carter Cheng<carter_cheng at yahoo.com> wrote: > Is there also an option to compile w/ clang on an x86 for Mipsel? A normal build of clang includes limited cross-compile support by passing in the "-ccc-host-triple" option, although it's still a bit of a work-in-progress. Nobody has added support for any Mips targets, but it's really