similar to: [LLVMdev] ARM support status (GHC/ARM new calling convention)

Hi Everyone, I have group of R jobs that should be submitted to the condor when I submit the jobs to the condor, they don't run and when I checked the Sched Log files the jobs are exiting with status code 10. Previously, the jobs ran well on condor but now when I submit the jobs on condor they aren't running.Can anyone explain the meaning of this? Here is my submit file: # Submit file

On Jun 16, 2011, at 1:35 PM, Karel Gardas wrote: > I'm working on implementing GHC specific call convention into LLVM 2.9. I've chosen LLVM 2.9 as a kind of stable reference point and I would like to know how mature is ARM code generation chain inside this release. I've had a hope that perhaps Apple as a main sponsor of LLVM is using LLVM for their ARM based iOS software

I don't know if GuaranteedTailCallOpt is in anyone's plans. It might be a good idea to implement some time. I am not sure what GHC's exact needs are, though. Cameron On Jun 17, 2011, at 1:49 PM, Karel Gardas wrote: > > Hello Cameron, > > thanks a lot for your fast answer, which just makes me curious if making ARM tailcalls on par with x86 in the future is on some of

They work pretty well now, at least on Thumb2 / Darwin. It is still fairly conservative about when to use tail calls, and doesn't support GuaranteedTailCallOpt, which might be necessary for GHC. Cameron On Jun 17, 2011, at 1:31 PM, Karel Gardas wrote: > > John, > > I've moved with patches to HEAD and unfortunately the comments about > disabling tailcalls do not go

Hello Cameron, thanks a lot for your fast answer, which just makes me curious if making ARM tailcalls on par with x86 in the future is on some of the development plans already? If not, then what do you think is the complexity of such work? Thanks! Karel On 06/17/11 10:41 PM, Cameron Zwarich wrote: > They work pretty well now, at least on Thumb2 / Darwin. It is still fairly conservative

Dear all, I don't get how llvm handles functions with __attribute__((noreturn)). It seems that LR register is backed up on the stack whilst it will never be used to return from a 'noreturn' function. I have this problem with a home-made backend but it seems that ARM flavour of clang has same behaviour. By the way, SP is also saved, I don't understand why. Is there a syntax error

Hi, I do not get your result. Do I miss something? $COMP_ROOT/clang++ --target=arm-arm-eabihf -march=armv8.2a+fp16 arm.cpp -S -o - -O3 .text .syntax unified .eabi_attribute 67, "2.09" .eabi_attribute 6, 14 .eabi_attribute 7, 65 .eabi_attribute 8, 1 .eabi_attribute 9, 2 .fpu crypto-neon-fp-armv8 .eabi_attribute 12, 4

Dear all I use arm-linux-gcc 2.95.2, because the code generated by version 3.X and 4.X can not run on SimpleScalar. So I use the arm-linux-gcc 2.95.2 *only*, the version is recommended by SimpleScalar. The code generated by arm-linux-gcc 2.95.2 can run on SimpleScalar. Now I want to use llvm/clang to generate ARM assembly code and arm-linux-gcc 2.95.2 to be assembler. Unfortunately, I got some

Simplescalar is not compatible with llvm because the binutils simplescalar is based on is ancient. Jim On Sep 26, 2012, at 12:21 AM, 陳奕梅 <ymchen at sslab.cs.nctu.edu.tw> wrote: > Dear all > > I use arm-linux-gcc 2.95.2, because the code generated by version 3.X and 4.X can not run on SimpleScalar. > So I use the arm-linux-gcc 2.95.2 *only*, the version is recommended by

Hello, am I wrong or the ARM c++ exceptions handling does not work? See the difference between assembly generated by clang and gcc with the following test code: #include <stdio.h> #include <exception> # test.cpp int main() { try { throw 20; } catch (int e) { printf("Exception Nr %d occurred\n", e); } return 0; }

I'm trying to find a way to emulate a floating point instruction, say a floating point add. My understanding is that in order to do that I need to execute setOperationAction(ISD::FADD, (MVT::f32, Expand); setOperationAction(ISD::FADD, (MVT::f64, Expand); in MyTargetISelLowering.cpp, MyTargetLowering::MyTargetLowering(...). However for some reason I'm still seeing a floating point add in

Hi andrea, R11 treated as frame pointer at arm backend , which is fixed again . Thanks Umesh On Tuesday, October 15, 2013, Andrea Mucignat <andrea at nestlabs.com> wrote: > Umesh, > Makes some sort of sense to me, OTOH: > If instead of choosing r11 as a "dummy" to align the stack we had chosen some other register in the range r0-r7 then we could have emitted the PUSH

Umesh, Makes some sort of sense to me, OTOH: If instead of choosing r11 as a "dummy" to align the stack we had chosen some other register in the range r0-r7 then we could have emitted the PUSH encoding T1 (2 bytes opcode) as opposed to the encoding T2 (which is a 4 bytes opcode). A On Tue, Oct 15, 2013 at 2:59 AM, Umesh Kalappa <umesh.kalappa0 at gmail.com>wrote: > Hi

Hi, I have this code: void platform_putchar(int, char); void out_char( char ch ); void out_char( char ch ) { platform_putchar (0, ch); } I'm compiling with the following clang invocation: $ /usr/local/vendor/toolchains/llvm/3.3/armv7m/bin/armv7m-none-eabi-clang -mcpu=cortex-m4 -mfloat-abi=soft -mthumb -nostdinc -ffreestanding -ffunction-sections -fdata-sections -fno-exceptions

On 10 September 2010 04:47, Liu <proljc at gmail.com> wrote: > trying this: > clang -march=armv7-a -mcpu=cortex-a9 -ccc-host-triple > arm-none-linux -ccc-gcc-name arm-none-linux-gnueabi-gcc a.c Hi Liu, That doesn't work for me. $ clang -march=armv7-a -mcpu=cortex-a9 -ccc-host-triple arm-none-linux -ccc-gcc-name arm-none-linux-gnueabi-gcc alias.c clang: warning: unknown

Hi Andrea, That is because the LR is the fixed register as per the http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf and out_char() function is not the leaf function ,Hence compiler tends to save and restore the LR and the save and restore of register r11 is to align stack for 8 bytes as per ARM EABI. Thanks ~Umesh On Tuesday, October 15, 2013, Umesh Kalappa

Looks like a problem with llvmc. Your example works fine with clang. ~/tmp $ cat foo.c void foo() { __asm__ volatile ("push {r4}\n\t"); } gilgamesh: ~/tmp $ clang -target arm-linux-eabi -S -Os foo.c -o - .syntax unified .eabi_attribute 20, 1 .eabi_attribute 21, 1 .eabi_attribute 23, 3 .eabi_attribute 24, 1 .eabi_attribute 25, 1 .file "foo.c" .text .globl foo

To recap, this is what I was trying to solve: This C code: int bar(int a, int b, int c, int d, int e, int f); int foo(int a, int b, int c, int d, int e ) { int x = 3*a; return bar3(a,b,c,d,e,x); } Produced the following assembly output: foo: push {r11, lr} sub sp, #8 bl bar add sp, #8 pop {r11, pc} The part I didn't like is that push/pop become

Hello, I want to compile MiBench by clang, and the target-ISA is armv4. The code generated using llvm-2.9, clang-2.9, and arm-linux-gcc (gcc version 2.95.2), simulator is sim-panalyzer 2.0.3 . I use these commends: $ clang -O3 -o hello.ll -c -emit-llvm hello.c $ llc -O3 -o hello.s -march=arm -mcpu=strongarm1100 hello.ll $ arm-linux-gcc -O3 -march=armv4 -mcpu=strongarm1100 -static

These errors are from the assembler, not LLVM. Specifically, your binutils is too old. Given that it doesn't even recognize the ".syntax" directive, they're *very* much too old. You need to upgrade. -Jim On Sep 24, 2012, at 3:31 AM, 陳奕梅 <ymchen at sslab5.cs.nctu.edu.tw> wrote: > Hello, > > I want to compile MiBench by clang, and the target-ISA is armv4. The