similar to: [LLVMdev] Big endian ARM?

On Saturday, June 02, 2012 10:20:03 AM Richard Pennington wrote: > Hi, > > I've been trying to set up clang/LLVM to compile for big endian ARM and I > need a little help. The code generation works for the most part and most of > my regression tests pass, but I noticed that code like this > > extern void g(void); > int *p; > > int main() > { > if (*p

On Jun 2, 2012, at 8:35 PM, Richard Pennington wrote: >> i.e. the test of the value is optimized to use a byte load, but the ldrb is >> done assuming a little endian address space. >> >> I've been snooping around, but can't seem to find where the conversion to a >> byte operation is done. Could someone point me in the right direction? >> > >

Rui Ueyama <ruiu at google.com> writes: > On Tue, Dec 5, 2017 at 1:22 PM, Rafael Avila de Espindola < > rafael.espindola at gmail.com> wrote: > >> Martin Richtarsky <s at martinien.de> writes: >> >> > Output looks as follows [1] Seems sh_offset is missing? >> >> That is what readelf prints as Off >> >> > [17] .rela.text

Hi all, Consider this ARM assembly code of a C function: 00008124 <foo>: 8124: push {r4, r6, r7, lr} 8126: add r7, sp, #8 8128: mov r4, r0 812a: ldrsb.w r0, [r2] 812e: cmp r0, #1 8130: itt lt 8132: movlt r0, #85 ;

> On Apr 27, 2018, at 7:48 AM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > Hi all, > > Consider this ARM assembly code of a C function: > > 00008124 <foo>: > 8124: push {r4, r6, r7, lr} > 8126: add r7, sp, #8 > 8128: mov r4, r0 > 812a: ldrsb.w

On Sun, 03 Jun 2012 11:39:21 -0700 Chris Lattner <clattner at apple.com> wrote: > On Jun 2, 2012, at 8:35 PM, Richard Pennington wrote: > >> i.e. the test of the value is optimized to use a byte load, but > >> the ldrb is done assuming a little endian address space. > >> > >> I've been snooping around, but can't seem to find where the >

As Adrian said, we'd need to see the source of foo() to assess what the location-list for bar ought to be. Without actually going to look, I would guess that 'poplt' is considered a conditional move, therefore r4's contents are not guaranteed after it executes (i.e. it is a clobber). If one operand of 'poplt' is 'pc' then of course it is also a conditional indirect

Thank you all for taking a look at this. I pasted the C source then deleted it because I was afraid that it was too long to read... Here's the code of *foo*. Its real name is *verifyPIN*. The variable *bar* is *userPin*. int *verifyPIN*(char **userPin*, char *cardPin, int *cpt) { int i; int status; int diff; if (*cpt > 0) { status = 0x55; diff = 0x55; for (i = 0; i

Hello, Has anyone taken a look at this bug? I really want to fix this, but as Paul pointed out, this requires a lot of care... Thank you for your help Son Tuan Vu On Fri, Apr 27, 2018 at 7:29 PM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > Thank you all for taking a look at this. I pasted the C source then > deleted it because I was afraid that it was too long to read...

Could you file a bug report about this (bugs.llvm.org <http://bugs.llvm.org/>)? If you don't have an account on bugzilla, I'd be happy to file one for you. Please provide exact instructions to reproduce the issue including any compilation flags. thanks, vedant > On May 7, 2018, at 9:16 AM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > Hello, > > Has

Hello LLVM Community (specifically anyone working with ARM Cortex-M), While trying to compile the Newlib C library I found that Clang10 was generating slightly larger binaries than the libc from the prebuilt gcc-arm-none-eabi toolchain. I looked at a few specific functions (memcpy, strcpy, etc.) and noticed that LLVM does not tend to generate load/store instructions with a register offset (e.g.

Hello Sjoerd, Thank you for your response! I was not aware that -Oz is a closer equivalent to GCC's -Os. I tried -Oz when compiling with clang and confirmed that the Clang's generated assembly is equivalent to GCC for the code snippet I posted above. clang --target=armv6m-none-eabi -Oz -fomit-frame-pointer memcpy_alt1: push {r4, lr} movs r3, #0 .LBB0_1: cmp

When the IR specifies a 32 bit load can it be changed to a narrower load? What if the load is from memory (e.g. a peripheral) that only supports 32-bit access? Consider the following IR: ---- target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:32" target triple = "thumbv7m-unknown-unknown" @f = external global i32 define zeroext i8 @bar() nounwind { L.0:

On Tue, Apr 23, 2013 at 10:29:32AM +0400, Anton Korobeynikov wrote: > Hello > > There is not support for big endian ARM at all. I guess he need to change the data layout string in ARMTargetMachine::ARMTargetMachine (ARMTargetMachine.cpp) from "e" to "E" to get big endian output? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information

Hi, I just realized that clang produces Thumb-2 instruction in code even when older CPU type which doesn't suport Thumb-2 is specified. Here is output: # /opt/llvm/bin/clang -S -ccc-host-triple arm-unknown-freebsd -mcpu=arm926ej-s -mfloat-abi=soft -v -o rrx.S rrx.c clang version 3.0 (http://llvm.org/git/clang.git 98138cdfdee05c0afbab2b209ce8cfe4a52474e1) Target: arm-unknown-freebsd Thread

> I guess he need to change the data layout string in > ARMTargetMachine::ARMTargetMachine (ARMTargetMachine.cpp) > from "e" to "E" to get big endian output? That would be a start, but I'd expect a significant number of bugs where the backend writers have assumed ARM was little-endian (lib/Target/Mips, which *does* support both, has many more endian checks in the

On Tue, Jan 24, 2012 at 08:36:17AM -0800, Esperanza de Escobar wrote: > No one is arguing that there aren't ABI specs or LLVM design > guidelines that say that unaligned accesses "should not", "could not" > or "aren't guaranteed to" work, because it's besides the point. No, it is the core of the issue. Standard C gives the compiler certain

Hello There is not support for big endian ARM at all. On Tue, Apr 23, 2013 at 9:26 AM, gamma_chen <gamma_chen at yahoo.com.tw> wrote: > The llvm ARM backend is little endian elf output as my examination as > below. Is it support bid endian by other llc options as below? > > llc -filetype=obj -march=arm // little endian > llc -filetype=obj -march=? or -otheroption=? // to

The llvm ARM backend is little endian elf output as my examination as below. Is it support bid endian by other llc options as below? llc  -filetype=obj -march=arm // little endian llc  -filetype=obj -march=? or -otheroption=? // to output big endian Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL:

I'm porting the musl C library to ARM Thumb. It looks like inline asm is failing in some cases. Here's one: The lseek system call looks like this: ... off_t result; return syscall(SYS__llseek, fd, offset>>32, offset, &result, whence) ? -1 : result; ... Which eventually goes through this macro: static inline long __syscall5(long n, long a, long b, long c,