similar to: [LLVMdev] configure llvm for 32-bit build on a 64-bit system

On Fri, Mar 4, 2011 at 12:38 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Junjie, > >> I have TOT of llvm and it builds 64-bit without issues on my 64-bit >> ubuntu.  My question is how to build 32-bit llvm on my 64-bit ubuntu ? >> I've not found any configure options to specify that. > > as well as "gcc -m32" and "g++ -m32" you may

Hi Junjie, > I have TOT of llvm and it builds 64-bit without issues on my 64-bit > ubuntu. My question is how to build 32-bit llvm on my 64-bit ubuntu ? > I've not found any configure options to specify that. as well as "gcc -m32" and "g++ -m32" you may want to configure with --build=i686-pc-linux-gnu Ciao, Duncan.

I'd like to add a pragma support in llvm. I am thinking about using a llvm intrinsic to represent each pragma, such as llvm.pragma (metadata, ...) where metadata describes a pragma. So if an application has: #pragma p1 .. #pragma p2... for (...) The llvm IR would be llvm.pragma (metadata..) // for p1 llvm.pragma (metadata..) // for p2 llvm IR for "for

Hi Chris, Thanks. I will see what I can do for this. Junjie On Wed, May 19, 2010 at 3:45 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 19, 2010, at 2:38 PM, Junjie Gu wrote: > >> Many compilers support per-loop pragma, such as loop unrolling (ie >> #pragma unroll=2).  Is there any LLVM project/effort going on >> in this area ? What is the expected

Thanks for comments/suggestions. Yes, attaching metadata to instructions will be good choices for many cases. But for loops, attaching metadata to back-edges requires that the front end to build loops, which is an additional task for the front end. And this task is really a backend's job, not the front end's. If the only concern is that it is hard for pragma intrinsics to stay with their

On Tue, Jun 1, 2010 at 5:42 PM, Junjie Gu <jgu222 at gmail.com> wrote: > Any suggestions/ideas ? IIUC, Chris suggested something like following ... header: br i1 %x, label %then, %label endif then: ... br i1 %y, label %loop_exit, label %header, !loop_pragma !1 endif: ... br i1 %z, label %loop_exit, label %header, !loop_pragma !2 loop_exit: ret i32 1 Where !1 and !2 are the

IANACE (I Am Not A Configury Expert :-), but I've been asked to reconfigure LLVM and LLVM-GCC to build with LLVM-GCC (perhaps more accurately, LLVM-G++). The patches to do this are short. In the LLVM tree, this suffices; it looks for LLVM-GCC first, and if that fails, falls back to GCC: Index: llvm.test/autoconf/configure.ac

On Wed, Sep 28, 2011 at 5:47 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Sep 28, 2011 at 3:27 PM, Junjie Gu <jgu222 at gmail.com> wrote: >> Instrinsic llvm.memory.barrier does not work as expected.  Is it a bug >> or it has not been implemented yet ? > > It's going away in favor of the new fence instruction (and I'll remove > it as soon

If LLVM would like to support OpenMP pragma in the future, not sure if attaching metadata to instructions is still a good choice. Junjie On Wed, Jun 2, 2010 at 11:08 AM, Junjie Gu <jgu222 at gmail.com> wrote: > Thanks for comments/suggestions. > > Yes, attaching metadata to instructions will be good choices for many > cases. But for loops, > attaching metadata to back-edges

On Mon, Jul 6, 2009 at 3:47 PM, Stuart Hastings<stuart at apple.com> wrote: =================================================================== > --- llvm-gcc.test/configure.in  (revision 74729) > +++ llvm-gcc.test/configure.in  (working copy) > @@ -993,10 +993,10 @@ >    # APPLE LOCAL begin dynamic-no-pic >    i[[3456789]]86-*-darwin*) >    

Please make sure when we are running the llvm test suite the "native" executables are still built with gcc (or another compiler) unless it's explicitly specified to be llvm-gcc. Thanks. Evan On Jul 6, 2009, at 3:47 PM, Stuart Hastings wrote: > IANACE (I Am Not A Configury Expert :-), but I've been asked to > reconfigure LLVM and LLVM-GCC to build with LLVM-GCC

Hello, Does anyone know how to build LLVM for the i386 architecture with snow leopard (this seems to have been the default for leopard). I've tried building with: ./configure CFLAGS="-arch i386" CXXFLAGS="-arch i386" LDFLAGS="-arch i386" OBJCFLAGS="-arch i386" --prefix=/Users/keith/share/ --enable-shared --enable-jit && make but I still end up

On Wed, Sep 28, 2011 at 3:27 PM, Junjie Gu <jgu222 at gmail.com> wrote: > Instrinsic llvm.memory.barrier does not work as expected.  Is it a bug > or it has not been implemented yet ? It's going away in favor of the new fence instruction (and I'll remove it as soon as dragonegg catches up). It should still work at the moment, though. > (1) false arguments do not work >

On Wed, Jun 2, 2010 at 11:08 AM, Junjie Gu <jgu222 at gmail.com> wrote: > Thanks for comments/suggestions. > > Yes, attaching metadata to instructions will be good choices for many > cases. But for loops, > attaching metadata to back-edges requires that the front end to build > loops, which is an > additional task for the front end. And this task is really a

Hi Keith, > Hello, Does anyone know how to build LLVM for the i386 architecture > with snow leopard (this seems to have been the default for leopard). > I've tried building with: > > ./configure CFLAGS="-arch i386" CXXFLAGS="-arch i386" LDFLAGS="-arch > i386" OBJCFLAGS="-arch i386" --prefix=/Users/keith/share/ > --enable-shared

Hi all, I found enough to explain the behaviour that I encountered. If I'm correct, the bugs are just in the dejagnu-based test machinery, not in LLVM itself. There seem to be two issues: Issue 1 is that the CC, CFLAGS, CXX, and CXXFLAGS settings are not reflected in the site.exp file. I had CC=gcc-4.2 CFLAGS="-m32 -Wl,-melf_i386" CXX=g++-4.2 CXXFLAGS=$CFLAGS

I am trying to add an analysis pass as a FunctionPass, and let LICM (LoopPass) depends upon it. So in LICM.cpp, I have the following: virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.setPreservesCFG(); AU.addRequired<DominatorTree>(); AU.addRequired<LoopInfo>(); AU.addRequiredID(LoopSimplifyID); AU.addRequired<AliasAnalysis>();

So I'm attempting to build Wine from the the source files in the Git repository. After running ./configure I took note of the dependencies that were missing and went about trying to download, build and install them. I then re-ran ./configure and it still couldn't find any of the libraries I had just downloaded. My initial thought was that Macports was building the libraries as 64-bit.

Hi all again, llvm is failing the 2006-11-30-NoCompileUnit and 2006-11-30-Pubnames tests on me. -m32 and --disable-multilib didn't change the outcome. Did I get the command wrong? I tried jo at kurier:~/Delta/llvm/test$ CFLAGS=--multilib make check See below for a transcript of the failed check. What next? Regards, Jo -- snip -- jo at kurier:~/Delta/llvm/test$ make check llvm[0]:

Many compilers support per-loop pragma, such as loop unrolling (ie #pragma unroll=2). Is there any LLVM project/effort going on in this area ? What is the expected way for implementing per-loop pragma, or general pragma ? Suggestions/comments ? Thanks Junjie