similar to: ARM/Thumb updates and some other minor tweaks

On 06/29/12 11:12 PM, Renato Golin wrote: > On 29 June 2012 17:46, Karel Gardas<karel.gardas at centrum.cz> wrote: >> Yes and no. Shortly: original GHC/ARM/LLVM port was done by Stephen on >> ARMv5/Qemu IIRC. I've later added whole VFP support and ARMv7 support. The >> code in GHC is properly #ifdefed, so if there is no VFP available on pre >> ARMv6, then

The parts of klibc specific to the arm architecture. Signed-off-by: H. Peter Anvin <hpa at zytor.com> --- commit 1eff7c685b36cd0120694fd4150b32a26168d926 tree 953dd1dbd2e994fc27c6cf5708fcbe06fe000d58 parent 5e5ce29210ac33a0b3704eb9ab5e5d5b55375575 author H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun 2006 16:58:16 -0700 committer H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun

> And be warned that the PC doesn't point at the next instruction when you use it like this - I believe you don't need to modify it at all if you swap the pop and the .long. Bernie, is it related to ARM pipeline? I'm interesting in this, is there any other additional information? On Fri, Mar 8, 2013 at 4:59 AM, Tim Northover <t.p.northover at gmail.com>wrote: > Hi Ashi,

Does the integrated assembler in the ARM backend support switching between ARM and Thumb modes in the same file? I'm having trouble with the following assembly: .thumb_func @ Enter ARM mode adr r3, 1f bx r3 .align 4 .code 32 1: push {r7} mov r7, r12 svc 0x0 pop {r7} @ Enter thumb mode adr r3, 2f+1 bx r3 .code 16 2: bx lr As a standalone .s file, GNU-as

On Nov 18, 2013, at 6:18 PM, Greg Fitzgerald <garious at gmail.com> wrote: > Does the integrated assembler in the ARM backend support switching > between ARM and Thumb modes in the same file? Yes. > I'm having trouble with > the following assembly: > > .thumb_func > @ Enter ARM mode > adr r3, 1f > bx r3 > .align 4 That .align is probably not

This allows building the arm assembly for iOS. This checks for the __APPLE__ preprocessor built-in define to determine whether this extra handling should be enabled. --- Makefile.am | 2 +- celt/arm/arm2gnu.pl | 23 +++++++++++++++++------ configure.ac | 8 ++++++++ 3 files changed, 26 insertions(+), 7 deletions(-) diff --git a/Makefile.am b/Makefile.am index c39d803..e76b204

Looks like the bug here is that the InlineAsm parser and the ARM code emitter point to two different TargetSubtargetInfo instances. The attached patch corrects the issue, but is incomplete. For starters, how can I remove that const_cast? Also, the patch does not restore the TargetSubtargetInfo to its original state. So if you changed from Thumb to ARM mode, but not back to Thumb, the code

Thanks Jim! I have updated the bug with your comments, I think it's a good start. Greg, let me know if that's not enough, I think I can help you from now on. cheers, --renato On 9 October 2012 23:58, Jim Grosbach <grosbach at apple.com> wrote: > > On Oct 7, 2012, at 3:14 AM, Renato Golin <rengolin at systemcall.org> wrote: > >> On 5 October 2012 17:48, Jim

On Oct 7, 2012, at 3:14 AM, Renato Golin <rengolin at systemcall.org> wrote: > On 5 October 2012 17:48, Jim Grosbach <grosbach at apple.com> wrote: >> The recent MachO data-in-code support should have fixed a lot of the problems. There's probably still some quirks in the specifics ($a vs. $t and making sure the symbols get into the ELF properly), but the core

Done, thanks. And added a code review here: http://llvm-reviews.chandlerc.com/D2255 -Greg On Fri, Nov 22, 2013 at 8:48 AM, Amara Emerson <amara.emerson at arm.com> wrote: > Hi Greg, > > Can you post any patches to the commits list, it'll have a better chance of > some of us seeing it and taking a look there. > > Cheers, > Amara > > -----Original

> I just tried the above code in a .s file and it worked fine for me. > Can you show exactly what you’re seeing that looks wrong? Thanks Jim. I can only reproduce the issue when that code is inline assembly in a bitcode file. Attached is a bitcode file and Makefile to demonstrate. Calling 'make' will dump two object files 'c.o' and 'asm.o'. The former is created

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

Hi, Bernie, Thanks for your reply! However, I still have problem by following edk2's code, my test code is attached, what I want to do is build it as a dynamic lib. But I get error from ld: ld: illegal text-relocation to _data_table in table.o from foo in use_table.o for architecture armv7 Do you have any suggestion to solve this? Thanks! //==begin table.c== int data_table[] = {0xff, 0xff};

Cool; glad to help. When I added the data region bits, I tried to keep the ARM-style annotations in mind a bit, so hopefully things will fit together without too much trouble. -Jim On Oct 10, 2012, at 12:05 PM, Renato Golin <rengolin at systemcall.org> wrote: > Thanks Jim! > > I have updated the bug with your comments, I think it's a good start. > > Greg, let me know

This would be best reported to Apple's Radar bug database at http://bugreport.apple.com/ but its whole website has been down for a while. I have a 100% reproducible Thumb-2 code generation error that occurs at all of the levels of optimization available in the Xcode 4.2 for Snow Leopard build settings GUI: -O0, -O1, -O2, -O3 and -Os. However the bad machine code only occurs in Release

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

On 29 June 2012 17:46, Karel Gardas <karel.gardas at centrum.cz> wrote: > Yes and no. Shortly: original GHC/ARM/LLVM port was done by Stephen on > ARMv5/Qemu IIRC. I've later added whole VFP support and ARMv7 support. The > code in GHC is properly #ifdefed, so if there is no VFP available on pre > ARMv6, then it's not used. ie. GHC STG floating points regs are then >