similar to: [LLVMdev] Is this bug in LLVM?

Hello. My name is Seung Jae Lee. I'd like to ask you onething about converting to ARM assembly code. I saved the simplest C code shown in your LLVM webpage as 'hello.c' And I made 'hello.bc' by "$ llvm-gcc hello.c -o hello". In order to make ARM assembly code, I typed "llc -march=arm hello.bc -o hello.arm" But, I met this error. llc: ARMISelDAGToDAG.cpp:73:

#include <stdio.h> int main() { printf("hello world\n"); return 0; } “$ llvm-gcc hello.c -o hello” “$ llc -march=arm hello.bc -o hello.arm" made error as follows: llc: ARMISelDAGToDAG.cpp:73: llvm::SDOperand LowerCALL(llvm::SDOperand, llvm::SelectionDAG&): Assertion `isVarArg == false && "VarArg not supported"' failed.

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,

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 Sorry for the late reply.. I managed to build the latest release of llvm. Now I get the following error when I try creating the bitcode file: llvm-gcc: --emit-llvm is not supported in this configuration. The configure options were : /home/arvind/llvm/llvm-gcc4.2-2.1.source/configure --prefix=/opt/llvm/ --enable-threads --disable-nls --disable-shared --enable-languages=c

Hi Nickhil, The Legalizer expects lower'd call is the node that produce the same number of values as the non-lowered node. That's what the assertion is checking. Take a look at the LowerCall routine for any other targets. You will see that in the non-void function case, it returns a MERGE_VALUES, i.e. all the results merged along with the chain. Cheers, Evan On Nov 15, 2006, at

Hi Evan, On Wed, Nov 15, 2006 at 10:17 -0800, Evan Cheng wrote: > Hi Nickhil, > > The Legalizer expects lower'd call is the node that produce the same > number of values as the non-lowered node. That's what the assertion > is checking. > > Take a look at the LowerCall routine for any other targets. You will > see that in the non-void function case, it

On Sep 24, 2007, at 2:25 AM, Arnold Schwaighofer wrote: > > On 24 Sep 2007, at 09:18, Evan Cheng wrote: >> +; RUN: llvm-as < %s | llc -march=x86 -mattr=+sse2 -stats -info- >> output-file - | grep asm-printer | grep 9 >> +; change preceeding line form ... | grep 8 to ..| grep 9 since >> +; with new fastcc has std call semantics causing a stack adjustment >>

Hi, I am trying to write a LowerCALL() function for my (custom) target ISA. All I need to do is map a CALL instruction directly onto an SDNode that takes an equal number of arguments (very much alike intrinsics, except that these are custom to my target.) I do not need to implement any call sequences, stack frames etc. I get the following assertion failure: llc: LegalizeDAG.cpp:834:

On 24 Sep 2007, at 09:18, Evan Cheng wrote: > +; RUN: llvm-as < %s | llc -march=x86 -mattr=+sse2 -stats -info- > output-file - | grep asm-printer | grep 9 > +; change preceeding line form ... | grep 8 to ..| grep 9 since > +; with new fastcc has std call semantics causing a stack adjustment > +; after the function call > > Not sure if I understand this. Can you illustrate

On Apr 16, 2008, at 10:07 AM, Arnold Schwaighofer wrote: > Hello Dale, > > this is an updated version of the tail call optimization patch for > powerpc. could you have a look at it? > > i added code to support ppc64 (untested, will try to get access to > ppc64 on a friend's machine). > incorporated evan's formatting suggestions. ;) > > will run another round

> > FastCC use to be caller pops arguments so there was no stack > > adjustment after the > > call to qux. Now FastCC has callee pops arguments on return semantics > > so the > > x86 backend inserts a stack adjustment after the call. > > > > _array: > > subl $12, %esp > > movss LCPI1_0, %xmm0 > > mulss

On Sep 25, 2007, at 12:01 AM, Arnold Schwaighofer wrote: >>> FastCC use to be caller pops arguments so there was no stack >>> adjustment after the >>> call to qux. Now FastCC has callee pops arguments on return >>> semantics >>> so the >>> x86 backend inserts a stack adjustment after the call. >>> >>> _array: >>>

Hi Arnold, This is a very good first step! Thanks! Comments below. Evan Index: test/CodeGen/X86/constant-pool-remat-0.ll =================================================================== --- test/CodeGen/X86/constant-pool-remat-0.ll (revision 42247) +++ test/CodeGen/X86/constant-pool-remat-0.ll (working copy) @@ -1,8 +1,10 @@ ; RUN: llvm-as < %s | llc -march=x86-64 | grep LCPI | count 3 ;

On Tue, Apr 22, 2008 at 12:30 AM, Evan Cheng <evan.cheng at apple.com> wrote: > More nitpicks: > ... > No need for else here. :-) Done > SPDiff = (int)CallerMinReservedArea - (int)ParamSize; > > Just change last statement to > int SPDiff = (int)... Done > > +bool > +PPCTargetLowering::IsEligibleForTailCallOptimization(SDOperand Call, > +

On Apr 22, 2008, at 4:58 AM, Arnold Schwaighofer wrote: > On Tue, Apr 22, 2008 at 12:30 AM, Evan Cheng <evan.cheng at apple.com> > wrote: >> More nitpicks: >> ... >> No need for else here. :-) > Done >> SPDiff = (int)CallerMinReservedArea - (int)ParamSize; >> >> Just change last statement to >> int SPDiff = (int)... > Done >>

A change has just been committed that changes the interface for TargetLowering::LowerCallTo and TargetLowering::LowerCall. Instead of passing a mess of parameters to these functions, a new structure has been created that encapsulates these parameters. The motivation is that additional fields can be added to this structure (with appropriate changes to SelectionDAGBuilder for populating the new

Hi Arnold, Thanks for the patch. Some questions and commons: 1. Have you test it against the llvm test suite? Does it work if fp elimination optimization is turned off? 2. Please follow llvm coding convention and make sure every line fits in 80 columns. 3. enum NameDecorationStyle { None, StdCall, - FastCall + FastCall, + FastCC // the normal fastcc calling convention }; Why is

Begin forwarded message: > From: Evan Cheng <evan.cheng at apple.com> > Date: 11 September 2007 19:26:39 GMT+02:00 > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Subject: Re: [LLVMdev] RFC: Tail call optimization X86 > Reply-To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > > Hi Arnold, > > Thanks for the patch. Some questions

Hi Patrik, > DAG.getMachineFunction().getFunction() only works in LowerFormalArguments (there it returns the callee), not in LowerCall (where it returns the caller, rather than the callee). You need to pass more information about the function type to LowerCall (besides partial information such as the isVarArg parameter). > > I can provide a patch if you are interested. (Unfortunately,