similar to: [LLVMdev] problem with function arguments in ARM EABI

> > 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

On Feb 8, 2007, at 10:46 AM, Lauro Ramos Venancio wrote: > I'm facing a problem with functions arguments. ARM EABI defines that > 8-bytes arguments must be 8-bytes aligned. For example: > > void @f(i32 %a, i64 %b) > > ARM EABI: > r0 <- %a > r2,r3 <- %b Ok. I suppose this makes it easier to use 64 bit store instructions. > > Darwin: > r0 <- %a >

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

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:

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

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: >

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 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

> > - Today LLVM supports ARM/EABI, but llvm-gcc don't. You must apply the > > patch: > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070319/046070.html > > That doesn't apply anymore :( You must use the llvm-gcc4 from the svn. It has some bug fixes that are important to ARM EABI and the patch should apply cleanly. Lauro

On Sep 16, 2009, at 5:58 AM, Kenneth Uildriks wrote: >> I recently made a major reorganization of the calling-convention >> lowering code which cleared away one of the major obstacles to >> doing this within codegen. >> >> Dan > > So what was the obstacle, and how was it cleared? The biggest obstacle is that there used to be two different methods for lowering

> I recently made a major reorganization of the calling-convention > lowering code which cleared away one of the major obstacles to > doing this within codegen. > > Dan So what was the obstacle, and how was it cleared? And how do you see the large struct return working in codegen? Anything you care to tell me would be welcome. I will be starting on this today or tomorrow.

Hi, Chris Lattner wrote: > In the 2.3 release, we included a list of the major LLVM API changes. If you > are working on upgrading your code from 2.3 to 2.4, I'd appreciate it if you > could compile a list of the major stumbling blocks you have, so that others > can benefit from your experience. Please send any info to the list, thanks! No major stumbling blocks during our

From: Evan Cheng [mailto:evan.cheng at apple.com] Sent: Thursday, April 19, 2012 10:47 AM To: Justin Holewinski Cc: llvmdev at cs.uiuc.edu; llvm-commits at cs.uiuc.edu; Vinod Grover Subject: Re: [llvm-commits] [PATCH][RFC] Add extra arguments to TargetLowering::LowerCall() so targets have more context in which to construct call chains TargetLowering::LowerCall is already a mess, I would really

In the 2.3 release, we included a list of the major LLVM API changes. If you are working on upgrading your code from 2.3 to 2.4, I'd appreciate it if you could compile a list of the major stumbling blocks you have, so that others can benefit from your experience. Please send any info to the list, thanks! -Chris

On Apr 19, 2012, at 12:46 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Apr 19, 2012, at 11:15 AM, Justin Holewinski wrote: > >> >> From: Evan Cheng [mailto:evan.cheng at apple.com] >> Sent: Thursday, April 19, 2012 10:47 AM >> To: Justin Holewinski >> Cc: llvmdev at cs.uiuc.edu; llvm-commits at cs.uiuc.edu; Vinod Grover >> Subject:

Thanks. This is going in the right direction IMHO. Obviously, please make sure you add comments to the data structure and convert all the targets first. Also, please don't forget to send an email to llvmdev to warn owners of all the out-of-tree targets about the ABI change. Evan On May 15, 2012, at 6:56 AM, Justin Holewinski <jholewinski at nvidia.com> wrote: > In response to this

In response to this discussion, I've prepared the attached patch as an initial prototype for the LowerCall/LowerCallTo change. All of the information currently needed by the back-ends, and the extra information needed by the NVPTX back-end, is now wrapped in a CallLoweringInfo struct. The various SelectionDAG classes have been modified so any calls to TargetLowering::LowerCallTo use this

On Apr 19, 2012, at 11:15 AM, Justin Holewinski wrote: > > From: Evan Cheng [mailto:evan.cheng at apple.com] > Sent: Thursday, April 19, 2012 10:47 AM > To: Justin Holewinski > Cc: llvmdev at cs.uiuc.edu; llvm-commits at cs.uiuc.edu; Vinod Grover > Subject: Re: [llvm-commits] [PATCH][RFC] Add extra arguments to TargetLowering::LowerCall() so targets have more context in which

> -----Original Message----- > From: Evan Cheng [mailto:evan.cheng at apple.com] > Sent: Wednesday, May 16, 2012 5:30 PM > To: Justin Holewinski > Cc: llvmdev at cs.uiuc.edu; llvm-commits at cs.uiuc.edu > Subject: Re: [llvm-commits] [PATCH][RFC] Add extra arguments to > TargetLowering::LowerCall() so targets have more context in which to > construct call chains > >

All, The attached patch adds two extra arguments to TargetLowering::LowerCall: RetTy and Args. These arguments are used in TargetLowering::LowerCallTo() to construct the Ins and OutVals parameters, but are not available to the target via LowerCall(). Some targets require this additional information, and the LowerCallTo() method is not virtual in TargetLowering. Instead of making that method