similar to: [LLVMdev] is anyone using the alpha backend?

On Oct 25, 2011, at 9:29 AM, David A. Greene wrote: > Dan Gohman <gohman at apple.com> writes: > >> I'm removing old targets that no longer appear actively maintained, >> to reduce the burden for target-independent codegen maintenance. >> >> Does anyone object to the removal of the Alpha backend? > > It would be a shame to lose it. Alpha is an

Hi Dan, Do you mind if I ask you what is the target-independent codegen maintenance? I imagine that target-independent codegen interface have to make with target-independent LLVM IR. I'm also interested in target-independent properties on LLVM. :) Thanks, Jin-Gu Kang ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of

Dan Gohman <gohman at apple.com> writes: > I'm removing old targets that no longer appear actively maintained, > to reduce the burden for target-independent codegen maintenance. > > Does anyone object to the removal of the Alpha backend? It would be a shame to lose it. Alpha is an excellent example of a good RISC-style ISA. There's at least one simulator out there

On Tue, Oct 25, 2011 at 12:20 PM, Chris Lattner <clattner at apple.com> wrote: > > On Oct 25, 2011, at 9:29 AM, David A. Greene wrote: > >> Dan Gohman <gohman at apple.com> writes: >> >>> I'm removing old targets that no longer appear actively maintained, >>> to reduce the burden for target-independent codegen maintenance. >>>

Dear LLVM members. I am compiling coreutils-7.4 package for ARM linux using LLVM 2.5 version. When i compiled 'od' program in coreutils package using LLVM 2.5, i could see the error message on llc processing. > llvm-gcc -emit-llvm ./od.c -c -o ./od.bc -other-options... > llc -march=arm ./od.bc -f -o ./od.s llc:

Hi Bob! I could not find llvm file for ARM target in llvm-gcc 4.2 front end source code. $llvm-gcc-src/gcc/config.gcc file alpha*-*-*) cpu_type=alpha need_64bit_hwint=yes # LLVM LOCAL begin out_cxx_file=alpha/llvm-alpha.cpp # LLVM LOCAL end ;; ... arm*-*-*) cpu_type=arm extra_headers="mmintrin.h" ;; ... i[34567]86-*-*) cpu_type=i386 # LLVM LOCAL begin

That is from 2.5, and just because there is nothing special listed in config.gcc does not mean it doesn't work. For 2.5, the ARM port of llvm-gcc did not require a separate llvm-arm.cpp source file, so nothing needed to be added to config.gcc. It worked fine as far as I know. For 2.6, you will see that there are some ARM-related changes to config.gcc in llvm-gcc. On Sep 30, 2009,

Hi Jin-Gu Kang! It are possible that the problem you are experiencing have already been solved in the current llvm 2.6 release tree and the current svn trunk. So try using llc from llvm 2.6 release branch or llvm pre2.7 svn trunk! It would be helpful if you could open a bugreport for this issue and attach the problematic od.bc since we need a testcase from the bitcode that exposes the bug inorder

Unlike llvm itself, llvm-gcc needs to be configured for a particular target architecture. It looks like you're using a copy of llvm-gcc that was built to generate x86 code. On Sep 30, 2009, at 6:27 AM, Jin Gu Kang wrote: > Dear LLVM members. > > I am compiling coreutils-7.4 package for ARM linux using LLVM 2.5 > version. > > When i compiled 'od' program in

Hi Duncan, I made a patch for dragonegg. This patch is for dragonegg to generate arm assembly code. Dragonegg is compiled with this patch after building gcc-4.6 as cross compiler for arm and then dragonegg can generate arm assembly code. It currently makes errors to build dragonegg and llvm from svn. so I made a patch using dragonegg-3.0 source code. (This patch doesn't support

Hi Renato, Firstly, I have been removing target specific information from struct type on bitcode. Target specific information are type size, type alignment, merged bitfields and so on. For example 1 struct test { 2 char a:3; 3 char b:4; 4 char c:3; 5 char d:2; 6 }; 7 8 struct test vm = {1, 2, 3, 1}; 9 10 int main(void) 11 { 12 int a; 13 vm.d = 1; 14 } Above

Sparc is a popular target for architecture simulators, and removing that back end would force people using such simulators to use some other compiler infrastructure. Sparc is also useful for University courses. I'd strongly discourage removing this back end. --Vikram Professor, Computer Science University of Illinois at Urbana-Champaign http://llvm.org/~vadve On Oct 25, 2011, at 4:00

Hi Jin Gu Kang > 5 %0 = type { i3, i4, i3, i2 } each of the above struct fields occupies 1 byte. If you were hoping that an i3 field would occupy only 3 bits then I am sorry, it doesn't work that way. Ciao, Duncan.

Thanks for applying this patch. I really appreciate that. Sincerely, Jin-Gu Kang

I'm removing old targets that no longer appear actively maintained, to reduce the burden for target-independent codegen maintenance. Does anyone object to the removal of the Sparc backend? Dan

Hi LLVM members, I have been working to make target independent memory layout for struct type(Aggregate type) in my team. I think that struct type has different memory layouts according to each target system in current LLVM. To implement target dependent concept for struct type, Frist, I have been implementing common type for struct type on bitcode at compilation time using llvm-gcc and then

Dear LLVM members. I am building llvm-gcc in version 2.5 for ARM target. I used command line option as following: >../src/configure --prefix=/home/jaykang10/Projects/LLVM/front_end_test/bin/ --enable-languages=c,c++ --enable-checking --enable-llvm=/home/jaykang10/Projects/LLVM/bin/ --disable-bootstrap --disable-multilib --target=arm-eabi And I got a error message as following: ... gcc -c -g

Hi Jin-Gu, > I made a patch for dragonegg. This patch is for dragonegg to generate arm > assembly code. thanks for working on this. > > Dragonegg is compiled with this patch after building gcc-4.6 as cross compiler > for arm and > > then dragonegg can generate arm assembly code. > > It currently makes errors to build dragonegg and llvm from svn. so I made a > patch

> struct T { > struct T (*p)(void); > } t; This testcase also generates infinite recursion when we use llvm-gcc for arm-target. Because return type of function pointer p's is struct type T which has one element, llvm-gcc for arm target calls a function which tries to chang aggregate return type to inner element. (For example, C.HandleAggregateResultAsScalar(Ty); -->

Hi Duncan, I send a modified patch which doesn't use reference type of CallingConv::ID. Thanks, Jin-Gu Kang -------------- next part -------------- A non-text attachment was scrubbed... Name: dragoneggARM.patch Type: application/octet-stream Size: 36680 bytes Desc: dragoneggARM.patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120130/a361f971/attachment.obj>