similar to: [LLVMdev] ARM Intruction Constraint DestReg!=SrcReg patch?

Hi, > I am using a cross compiler to compiler for the arm5 architecture. For this > architecture it is not allowed that a destination register is also used as source > register. > In 2007 a patch was discussed at the mailing list, however my compiler still is > producing this result. Does anyone know if this patch is actually applied? > > * I use the following arguments:

Hi, Paul Curtis wrote: > If you read the Arm Architecture document for ARMv5, it states for MUL: > > "Operand restriction: Specifying the same register for <Rd> and <Rm> was > previously described as producing UNPREDICTABLE results. There is no > restriction in ARMv6, and it is believed all relevant ARMv4 and ARMv5 > implementations do not require this

> Thanks for the review and checkin. Thanks for the patch! > Regarding elf-thumbfunc-reloc.ll, it seems to me that current ARMAsmParser > doesn't recognize "(PLT)", so something like "bl foo(PLT)" doesn't work > consequently. And I don't know how to write .s to test this without (PLT). NP. Can you just add that as a FIXME in elf-thumbfunc-reloc.ll?

On Wed, May 18, 2011 at 12:05 AM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: >> Regarding elf-thumbfunc-reloc.ll, it seems to me that current ARMAsmParser >> doesn't recognize "(PLT)", so something like  "bl foo(PLT)" doesn't work >> consequently. And I don't know how to write .s to test this without (PLT). > > NP.

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

This code or subtle variations of it appears in multiple targets. It tries to convert from a register to a register class using getRegClass, but getRegClass is really supposed to take a register class enum value and get the register class object for it. It doesn't convert a register to a class. In fact there's not always a single or canonical class for a given register. What is the right

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

Jim/Tim/Renato, A few days ago (has it been weeks now?) we discussed a codegen problem on armv4t having to do with lo->lo register copies. I'd like to start that discussion again, this time with a patch. A brief summary of the problem for folks who didn't catch the discussion earlier, and those like me who forget what they ate for breakfast: ;] The mov instruction on armv4t

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

Hi, The PHI elimination pass calls the function copyRegToReg for copy placement and then later tries to setkill to the temporary virtual register used in copy placement. For this setkill action it looks only in one instruction (last instruction for copyRegToReg) for virtual register with no use. My target has only one register and I can't do copyRegToReg in one instruction only. So I

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