similar to: [LLVMdev] Request to review of patch for llvm-gcc

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

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 Duncan, I appreciate your kind review. I'd like to help you to build an ARM cross compiler. I built GCC as following. 1. Download "arm-2010.09-50-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2" You can find this file on https://sourcery.mentor.com/sgpp/lite/arm/portal/release1600. (Please click "IA32 GNU/Linux TAR" on Packages.) 2. Extract this file on your linux

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,

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

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

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

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>

Hi Jin Gu Kang, > I send a modified patch which doesn't use reference type of CallingConv::ID. thanks for the patch. I applied it with some cosmetic changes, and now I can compile bzip2 for ARM! I didn't check if the compiled program works though :) Ciao, Duncan.

Jin-Gu Thanks for your suggestion. Using liveness information for virtual register is a good idea, but what I am working on is a source-to-source compiler, so I prefer to use FunctionPass instead of MachineFunctionPass. Interestingly I found a FunctionPass example for classic liveness data flow equation. http://cs.pub.ro/~cpl/wiki/images/1/15/Hello.txt

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

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

I have a few pass managers, but only one of them has been initialized with addPassesToEmitCode, how do I find how many passes are added to a function pass manager ? Thank you, Xin On Fri, May 20, 2011 at 1:00 PM, <llvmdev-request at cs.uiuc.edu> wrote: > Send LLVMdev mailing list submissions to > llvmdev at cs.uiuc.edu > > To subscribe or unsubscribe via the World Wide

> 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 Renato, First, I appreciate your answer again. :) >> %Char = type { c3, c4, c3, c2 } >> %Short = type { s3, s4, s3, s2 } >> %Int = type { i3, i4, i3, i2 } > See, i is not for int (the C data type) but for every integer type on > any language/platform combination. Normally, booleans are i1 and char > i8, in ARM short is 16 and int is 32, and all of them use the

On 20 October 2010 06:22, Jin Gu Kang <jaykang10 at imrc.kist.re.kr> wrote: > The IR in an previous e-mail is incomplete so far and > I am converting it to various shape. Hi Jin, No worries. I'm interested in the outcome, so I'm playing the devil's advocate to make sure your proposal is consistent with the rest of LLVM. > %Char = type { c3, c4, c3, c2 } > %Short =

Hi Talin, I had a talk in London developer meeting about More Target Independent Bitcode. (You can download the slides from http://llvm.org/devmtg/2011-09-16/) I have been also trying to make bitcode with more higher abstraction level. I made new compilation strategy using more target indepent bitcode as followins, (This didn't consider about Jit or Interpreter like lli) C/C++ source code

I am pleased to discuss probleams with you. :) (Your answer is really helpful to me). If you don't mind I would often like to ask you a question. Thanks, Jin-Gu Kang

Hi renato, First, I really appreciate your answer. :) The IR in an previous e-mail is incomplete so far and I am converting it to various shape. My team members decided to add new types to solve the bitfield's alignment problem. Let's consider your previous examples: struct testChar { char a:3; char b:4; char c:3; char d:2; }; struct testShort { short a:3; short b:4; short c:3;

Hi Talin, I too agree 100% with Dan's words, and this could be a good pointer for Jin-Gu Kang to continue on his pursuit for a better target-independent bitcode. Also, add your backwards compatibility issue to debug metadata in IR, in which fields appear or disappear without notice. But I think you hit a sweet spot here... On 4 October 2011 21:23, Talin <viridia at gmail.com> wrote: