similar to: [LLVMdev] current feature/platform supported list

On 11/16/06, Chris Lattner <sabre at nondot.org> wrote: > > I'm preparing the release announcement: > > Does LLVM's X86-64 backend work for anything other than Darwin? Does it > work on linux in -static mode? I am using it on linux in -static mode. > Does LLVM's debug support work on anything other than linux+darwin? Does > it work on cygwin? > >

On Fri, 8 Sep 2006, [UTF-8] Rafael Esp?ndola wrote: > I am not sure if it is the correct solution, but the attached patch > fixes the problem. Your solution is correct, in that it will work and follows with the current ifdef approach. I applied this patch though, which doesn't use the ifdefs, hopefully it is more robust:

With the patchs I send earlier, it is possible to compile llvm-gcc in a amd64 with ../trunk/configure --enable-llvm=/home/rafael/dev/llvm/build/ --enable-checking --prefix=/home/rafael/dev/llvm/gcc/inst/ --enable-languages=c --disable-threads --disable-shared --disable-multilib --program-prefix=llvm- Enabling shared libraries causes the build to fail while linking libgcc. Apparently llvm-gcc

Bugs 1519 and 1521 currently prevent a clean bootstrap on Linux x86_64. I was able to hack it to work :-) The attached patch includes two parts. One is a tentative fix bug 1519: just set LastFieldStartsAtNonByteBoundry in allFieldsAreNotBitFields. The other one is a plain hack. llvm-gcc and gcc disagree on how to pass some structures, so stage2 gcc fails to use the libcpp compiled by gcc. So I

In the ARM backend, functions (and other 32 bit constants) are placed in a pool and loaded when needed. A problem with this is that ".weak" directives must be printed in the pool. This is not supported in the standard printer, so I think that I have found the first use for MachineConstantPoolValue :-) Creating the constant is easy, but I have two problems: 1) what are the methods

> Please lemme know if it works. It does. Thanks. > I don't know what that is :( I believe that code compiled without -fpic is going into a DSO. This creates text relocations that are not supported on linux/amd64 (http://people.redhat.com/drepper/dsohowto.pdf). > -Chris Rafael

Building with --enable-llvm failed latter on when compiling libojc: configure:5099: checking for exception model to use configure:5131: /home/rafael/dev/gcc/build/gcc/xgcc -B/home/rafael/dev/gcc/build/gcc/ -B/i686-pc-linux-gnu/bin/ -B/i686-pc-linux-gnu/lib/ -isystem /i686-pc-linux-gnu/include -isystem /i686-pc-linux-gnu/sys-include -c -xobjecti ve-c -fgnu-runtime -fobjc-exceptions -S conftest.c

> > Why it is named RETFLAG? > > Historical reason. Originally we didn't have nodes that could > *optionally* have an input flag. A better design, e.g. on PPC would be to > have a PPCISD::RET node, which takes an optional input flag, and always > lower RET to it. I See. I will try to always lower to "(mov)*;bx lr" on ARM. > Flag in the SelectionDAG stuff is

> Funny, I've just got one student for exactly same task -- writing ARM > backend. Of course, the student might well disappear by the time new term > begins and might not produce anything usable for a year ;-) I am currently reading and hacking the code. I would be very glad to work with your student if that is not a problem. > I wrote one backend (private) in a couple of months.

I am trying to build llvm-gcc4 on a amd64. I had to add the attached patch to get the build system to select the correct library. Now the build fails while compiling a code that has __builtin_va_copy. The attached test.i fails with: cc1: ../../trunk/gcc/llvm-convert.cpp:443: llvm::Value* TreeToLLVM::Emit(tree_node*, llvm::Value*): Assertion `(isAggregateType(((exp)->common.type)) == (DestLoc

The ARM has a multiply instruction of the form Rd=Rm*Rs where Rd != Rm. How can I add this requirement to the instruction definition? Thanks, Rafael

The ARM has some very powerful and complex addressing modes. For example, the data processing instructions (and, orr, add, ..) have an addressing mode that has 11 options (imm, reg, and 9 reg + some shift). I am considering 3 ways to implement this: 1) define one instruction that has an ARM specific addressing mode that covers all 11 possibilities. 2) define 11 instructions. 3) a mix of the two

On Wed, 6 Dec 2006, [UTF-8] Rafael Esp?ndola wrote: > In the ARM backend, functions (and other 32 bit constants) are placed > in a pool and loaded when needed. Has this approach been replaced with your later constant pool patch? -Chris > A problem with this is that ".weak" directives must be printed in the > pool. This is not supported in the standard printer, so I think

Hi Chris, > On Sun, 17 Sep 2006, [UTF-8] Rafael Esp?ndola wrote: > > The ARM has a multiply instruction of the form Rd=Rm*Rs where Rd != > > Rm. How can I add this requirement to the instruction definition? > > ... > > I'd like to make the regalloc interfaces more powerful to be able to > capture this sort of thing, but I'm not very familiar with ARM.

Hi Rafael, Can you file a bugzilla report? Thanks, Evan On Jun 13, 2007, at 4:39 PM, Rafael Espíndola wrote: > Using a little bit of gdb I was able to dump the .ll. It is attached. > > Running llvm-as on it produces: > > llvm-as: assembly parsed, but does not verify as correct! > Attribute ZExt should only apply to Integer type! > void (i64, i64, i8* sext , i8)*

Hi, I recently bootstrapped gcc4 frontend on a i686-linux-gnu too. As I notice, if the llvm "tools-only " was build with srcdir != objdir , the building of llvm-gcc4-1.7.source encountered mistakes of unable to find some header files. So I just edited llvm-gcc4-1.7.source/gcc/Makefile.in and a line like this: INCLUDES += -I$(LLVMOBJDIR)/include With this change, the building errors

Compiling the following C code -------------------------------------------- long long f4(void) { return (long long)INT_MAX + 1; } ------------------------------------------- produces ------------------------------------------ long %f4() { entry: ret long -2147483648 } ------------------------------------------ but in 64 bits, -2147483648 != 2147483648. As a result, the x86 output has

On Wed, 31 May 2006, [UTF-8] Rafael Esp?ndola wrote: >> We don't want the copy and shift to wander apart from each other (e.g. we >> don't want another shift to get scheduled in between them), so we flag >> them together. In practice, these copies usually get coallesced away. > In the second case shl explicitly uses CL. Shouldn't the register > allocator be

> Looks good, one request though: if practical, it would be nice to switch > this to be set<GlobalValue*> instead of set<std::string>. Attached > -Chris Rafael -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm.patch Type: text/x-patch Size: 7646 bytes Desc: not available URL:

I am trying to bootstrap the just released gcc 4.0.1 and the cvs head llvm. I was able to build the llvm tools without a problem. gcc has a small problem (from the apple branch IIRC): libojc is built unconditionally, so objc must be in the --enable-languages option for the build to be successful. Building the rest of llvm fails with llvm[3]: Compiling crtend.ll to crtend.bc for Debug build