Displaying 20 results from an estimated 3000 matches similar to: "[LLVMdev] LLVM ARM code error"
2006 Nov 09
3
[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:
2008 Jan 28
2
[LLVMdev] llc fails to generate code for arm
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,
2006 Nov 10
0
[LLVMdev] Is this bug in LLVM?
> Hello. My name is Seung Jae Lee.
Hi Seung
> 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,
2008 Jan 28
0
[LLVMdev] llc fails to generate code for arm
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
2007 Sep 24
2
[LLVMdev] RFC: Tail call optimization X86
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
2006 Nov 15
2
[LLVMdev] LowerCALL (TargetLowering)
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:
2006 Nov 15
0
[LLVMdev] LowerCALL (TargetLowering)
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
2007 Sep 24
0
[LLVMdev] RFC: Tail call optimization X86
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
;
2007 Sep 24
0
[LLVMdev] RFC: Tail call optimization X86
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
>>
2008 Feb 04
1
[LLVMdev] llc fails to generate code for arm
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
2006 Nov 15
1
[LLVMdev] LowerCALL (TargetLowering)
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
2007 Sep 25
2
[LLVMdev] RFC: Tail call optimization X86
> > 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
2008 Apr 21
0
[LLVMdev] RFC: PowerPC tail call optimization patch
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
2007 Sep 11
0
[LLVMdev] RFC: Tail call optimization X86
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
2007 Sep 23
2
[LLVMdev] RFC: Tail call optimization X86
The patch is against revision 42247.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tailcall-src.patch
Type: application/octet-stream
Size: 62639 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070923/4770302f/attachment.obj>
2008 Apr 16
2
[LLVMdev] RFC: PowerPC tail call optimization patch
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 of testing (llvm-test) on my powerpc g4/800
when i get the okay to commit. testing on this machine takes
2007 Oct 05
0
[LLVMdev] RFC: Tail call optimization X86
Hi Evan,
I incoporated the changes you request but to the following i have got
a question:
> Also, moving the option
> there will allow us to change fastcc ABI (callee popping arguments)
> only when this option is on. See Chris' email:
I am not to sure on that. because that would make modules compiled
with the flag on incompatible with ones compiled without the flag off
as
2008 Apr 22
2
[LLVMdev] RFC: PowerPC tail call optimization patch
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,
> +
2015 Jan 19
2
[LLVMdev] [INCOMPLETE] [GC] Support wrapping vararg functions in statepoint
I actually need this feature quite badly in my untyped language
compiler: since I support first-class functions, I've made the types of
all functions a standard vararg (so I can box them).
The implementation crashes when I try to read out the value of
gc.result. Hints as to what might be wrong?
Signed-off-by: Ramkumar Ramachandra <artagnon at gmail.com>
---
2007 Sep 25
0
[LLVMdev] RFC: Tail call optimization X86
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:
>>>