similar to: [LLVMdev] constant pool in large functions

Hi Lauro, This is a very tricky problem to resolve. Basically you need a pass just before code emission to find the proper locations for each constant pool. That means you need: 1. Exact size of each instruction. This can be added with a custom instrinfo that specify instruction length for each target instruction. 2. Probably some kind of constantpool pseudo instruction. The pass can then

For everyone understand which code must be emitted to implement TLS, I will paste the code generated by gcc for a simple function: __thread int a = 1; int f(){ return a; } gcc teste.c -o teste.s -S -O2 (arm-linux-gnueabi): .global a .section .tdata,"awT",%progbits <== special section for tls symbols .align 2 .type a, %object

Adds external weak symbols of constant pool to ExtWeakSymbols set. Lauro -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20061220/1aaa0c7b/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm.patch Type: text/x-patch Size: 1021 bytes Desc: not available

without tabs Lauro 2006/12/20, Bill Wendling <isanbard at gmail.com>: > > Hi Lauro, > > Just a stylistic remark; In your "llvm.patch" file, there are tabs in > these lines: > > + if (GV->hasExternalWeakLinkage()) { > + ExtWeakSymbols.insert(GV); > + } > > Others will need to review the patch for correctness, though. >

Hi all, I did a performance test of two real applications (FFMPEG and GTK) on ARM. For more details see: http://laurovenancio.wordpress.com/2007/08/07/llvm-perf-tests/ Lauro

I think, we must move function arguments lowering from frontend to LLVM core. This lowering is generating machine dependent bytecode. See http://llvm.org/bugs/show_bug.cgi?id=1230 Lauro 2007/2/26, Chris Lattner <sabre at nondot.org>: > On Mon, 26 Feb 2007, Lauro Ramos Venancio wrote: > > The problem is: llvm-gcc generates the same bytecode for both functions: > > > >

Hi Lauro, Just a stylistic remark; In your "llvm.patch" file, there are tabs in these lines: + if (GV->hasExternalWeakLinkage()) { + ExtWeakSymbols.insert(GV); + } Others will need to review the patch for correctness, though. -bw On 12/20/06, Lauro Ramos Venancio <lauro.venancio at gmail.com> wrote: > Adds external weak symbols of constant pool to ExtWeakSymbols set.

The ARM EABI (AAPCS) defines: - i64 values are 8-bytes aligned - "The alignment of an aggregate shall be the alignment of its most-aligned component." So, struct ss { int x; int y; }; void f(int a, struct ss b); r0 <- a r1-r2 <- b void g(int a, long long b); r0 <- a r2-r3 <- b The problem is: llvm-gcc generates the same bytecode for both functions: declare void

Hi Koen, The process to build llvm-gcc as a crosscompiler is basically the same as build a normal gcc as crosscompiler. The differences: you need a LLVM installed (compiled for the host). You must configure llvm-gcc with --enable-llvm. Problems: - Today LLVM supports ARM/EABI, but llvm-gcc don't. You must apply the patch:

Rafael, Remember that the qemu <= 0.9.0 can misexecute code compiled by LLVM. I think you should test using qemu CVS. Lauro 2007/11/2, Rafael Espindola <espindola at google.com>: > Hello, > > I am trying to bootstrap on ARM linux EABI using a qemu chroot to > better test my changes on at least one more architecture. > > I am using the following configure line: >

Hi Arvind, To use llvm inside scratchbox you must use a newer qemu. See http://setanta.wordpress.com/2007/11/20/qemu-arm-eabi-no-scratchbox/ (in Portuguese, but the important things are in bash :) ) I don't know if it is the problem in this case, but it should be the first attempt. Lauro 2008/1/21, Rafael Espindola <espindola at google.com>: > On 21/01/2008, Arvind Ayyangar

Hi all, I'm trying to make a toolchain for arm-linux-gnueabi using the llvm-gcc. To do this, I made some changes in crosstool 0.42. Everything goes fine until llvm-gcc tries to compile the glibc. llvm-gcc can't compile glibc because it doesn't support TLS (Thread Local Storage). I know there is a bug report about TLS (PR941). Is there someone implementing TLS in LLVM and llvm-gcc?

> > Yes, you need to override both LowerArguments and LowerCallTo. All of > the current targets / abi's use the default implementation in > SelectionDAGISel.cpp But I guess ARM EABI will be the first. :-) As > far as I can see, this is the only clean way to do it. I expect the > ARM EABI specific implementation will be quite a bit simpler than the > default implementation

HI Arvind, I think you are using an old llc version. VarArg support was implemented a long time ago. Lauro 2008/1/28, Arvind Ayyangar <arvind.ayyangar at gmail.com>: > Hi all, > I had little success installing llvm inside scratchbox for an ARM > build so have been trying to generate assembly code for arm using the > llc utility. However, llc fails to generate code for

Hi Lauro, On 14 Aug 2007, at 01:10, Lauro Ramos Venancio wrote: > Hi all, > > I did a performance test of two real applications (FFMPEG and GTK) on > ARM. For more details see: > http://laurovenancio.wordpress.com/2007/08/07/llvm-perf-tests/ Could you give me some more information about the applications you compiled and ran? Where can I obtain source codes, which input did

Hi all, I had little success installing llvm inside scratchbox for an ARM build so have been trying to generate assembly code for arm using the llc utility. However, llc fails to generate code for arm. Output is as below... arvind at zeus:~/tools/llvm/del$ llc main.bc -o mainarm -filetype=asm -march=arm -f llc: ARMISelDAGToDAG.cpp:73: llvm::SDOperand LowerCALL(llvm::SDOperand,

Hello, I am trying to bootstrap on ARM linux EABI using a qemu chroot to better test my changes on at least one more architecture. I am using the following configure line: ../gcc/configure --prefix=/home/espindola/install/ --program-prefix=llvm- --enable-languages=c --disable-shared --disable-multilib --enable-llvm=/home/espindola/build --enable-checking arm-linux-gnueabi The bootstrap fails

Hi Mikael, You are obtaining warning, not an error, right? The most arm cores, including arm1136, can execute mul with rd = rm. So, you can ignore this warning. Lauro 2007/6/12, Peltier, Mikael <m-peltier at ti.com>: > > > > > Hello, > > > > I want to compile a LLVM file into an executable running on ARM platform. > > I use LLVM 2.0 with the following

On Mon, 26 Feb 2007, Lauro Ramos Venancio wrote: > The problem is: llvm-gcc generates the same bytecode for both functions: > > declare void @f(i32, i64) > declare void @g(i32, i64) > > I can't differ an i64 argument from a struct argument. Oops. You can fix this by changing llvm-gcc: gcc/llvm-abi.h Grep for instances of Int64Ty there. I can help answer any q's you

I am ok with adding an attribute but don't like to add two of them as you've described. I don't think you need the "sequential piece ID" to deal with this issue, no? You just need a little extra bookkeeping in the target lowering code. Alternatively, you can use a "original alignment" attribute (i.e. alignment of unexpanded argument). That would be a 5-bit