search for: ldrb

...r4, r0 812a: ldrsb.w r0, [r2] 812e: cmp r0, #1 8130: itt lt 8132: movlt r0, #85 ; 0x55 8134: poplt {r4, r6, r7, pc} // a function return 8136: ldrb.w ip, [r1, #3] 813a: ldrb.w lr, [r4, #3] 813e: movs r0, #85 ; 0x55 8140: cmp lr, ip 8142: bne.n 8168 <foo+0x44> 8144: ldrb.w ip, [r1, #2] 8148: ldrb...

...ldrsb.w r0, [r2] > 812e: cmp r0, #1 > 8130: itt lt > 8132: movlt r0, #85 ; 0x55 > 8134: poplt {r4, r6, r7, pc} // a function return > > 8136: ldrb.w ip, [r1, #3] > 813a: ldrb.w lr, [r4, #3] > 813e: movs r0, #85 ; 0x55 > 8140: cmp lr, ip > 8142: bne.n 8168 <foo+0x44> > > 8144: ldrb.w ip, [r1, #2] &g...

...r4, r0 812a: ldrsb.w r0, [r2] 812e: cmp r0, #1 8130: itt lt 8132: movlt r0, #85 ; 0x55 8134: poplt {r4, r6, r7, pc} // a function return 8136: ldrb.w ip, [r1, #3] 813a: ldrb.w lr, [r4, #3] 813e: movs r0, #85 ; 0x55 8140: cmp lr, ip 8142: bne.n 8168 <foo+0x44> 8144: ldrb.w ip, [r1, #2] 8148: ldrb...

...t;> >> 8130: itt lt >> >> 8132: movlt r0, #85 ; 0x55 >> >> 8134: poplt {r4, r6, r7, pc} // a >> function return >> >> >> >> 8136: ldrb.w ip, [r1, #3] >> >> 813a: ldrb.w lr, [r4, #3] >> >> 813e: movs r0, #85 ; 0x55 >> >> 8140: cmp lr, ip >> >> 8142: bne.n 8168 <foo+0x44> >> &...

...812e: cmp r0, #1 > > 8130: itt lt > > 8132: movlt r0, #85 ; 0x55 > > 8134: poplt {r4, r6, r7, pc} // a > function return > > > > 8136: ldrb.w ip, [r1, #3] > > 813a: ldrb.w lr, [r4, #3] > > 813e: movs r0, #85 ; 0x55 > > 8140: cmp lr, ip > > 8142: bne.n 8168 <foo+0x44> > > > > 8144:...

...812e: cmp r0, #1 > > 8130: itt lt > > 8132: movlt r0, #85 ; 0x55 > > 8134: poplt {r4, r6, r7, pc} // a function return > > > > 8136: ldrb.w ip, [r1, #3] > > 813a: ldrb.w lr, [r4, #3] > > 813e: movs r0, #85 ; 0x55 > > 8140: cmp lr, ip > > 8142: bne.n 8168 <foo+0x44> > > > > 8144:...

...or example, on x86_64 reading 32 bits with 1 2 and 4 byte alignment produces in all cases: movl (%rdi), %eax But on armv6 the aligned case is ldr r0, [r0] the 2 byte aligned case is ldrh r1, [r0, #2] ldrh r0, [r0] orr r0, r0, r1, lsl #16 and the unaligned case is ldrb r1, [r0] ldrb r2, [r0, #1] ldrb r3, [r0, #2] ldrb r0, [r0, #3] orr r1, r1, r2, lsl #8 orr r0, r3, r0, lsl #8 orr r0, r1, r0, lsl #16 On armv7 it is a single ldr on all cases. Now, I don't really know how much we support *host* architectures without a unalig...

...ian 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 & 0x01000000) g(); } generates ldr r0, [r0] ldrb r0, [r0, #3] tst r0, #1 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 t...

...*)dst; for (size_t i = 0; i < len; ++i) *((char*)(dst + i)) = *((char*)(src + i)); return save; } clang --target=armv6m-none-eabi -Os -fomit-frame-pointer memcpy_alt1: push {r4, lr} cmp r2, #0 beq .LBB0_3 mov r3, r0 .LBB0_2: ldrb r4, [r1] strb r4, [r3] adds r1, r1, #1 adds r3, r3, #1 subs r2, r2, #1 bne .LBB0_2 .LBB0_3: pop {r4, pc} arm-none-eabi-gcc -march=armv6-m -Os memcpy_alt1: movs r3, #0 push {r4, lr} .L2: cmp r3,...

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 RELA 0000000000000000 071423 001728 18 > 1 4 8 The offset of rela text should have been aligned, but it is not. Can you report a bug on icc? As a work around using the gnu assembler if possible

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

...lang 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 r2, r3 beq .LBB0_3 ldrb r4, [r1, r3] strb r4, [r0, r3] adds r3, r3, #1 b .LBB0_1 .LBB0_3: pop {r4, pc} On the other hand, -O2 in GCC still uses the register-offset load and store instructions while Clang -O2 generates the same assembly as -Os: immediate-offset (0 offset)...

...neration 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 & 0x01000000) g(); > } > > generates > > ldr r0, [r0] > ldrb r0, [r0, #3] > tst r0, #1 > > 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...

...2" target triple = "thumbv7m-unknown-unknown" @f = external global i32 define zeroext i8 @bar() nounwind { L.0: %rv.0 = alloca i8 %0 = load i32* @f %1 = trunc i32 %0 to i8 ret i8 %1 } ---- Which for the arm cortex-m3 generates: ---- bar: movw r0, :lower16:f movt r0, :upper16:f ldrb r0, [r0] bx lr ---- Although we are only interested in low 8-bits, the load MUST be a 32-bit load. Using a "load volatile" fixes this, but this is overkill as the memory location is not volatile. Am I missing something, or is this a bug? brian

...set GPR:$RdLo, (ARMaddc (set GPR:$Rd, mul GPR:$Rn, GPR:$Rm), GPR:$RdLo)), (set GPR:$RdHi, (ARMadde (sra GPR:$Rd, (i32 31)), GPR:$RdHi, CPSR)))] This results in 'expected identifier in dag init' error. Obviously something is wrong in this pattern, I have not figured out what that is ? 2) ldrb r2, [r2] ldrb r3, [r3] smlal r0, r1, r3, r2 ==> smlalbb r0, r1, r3, r2 def : ARMV5MOPat<(smlal GPRnopc:$RdLo, GPRnopc:$RdHi, (sra (shl GPR:$a, (i32 24)), (i32 24)), (sra (shl GPR:$b, (i32 24)), (i32 24))), (SMLALBB GPRno...

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? >> > > I've figured out my problem. I did...

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. The point is that unaligned 32-bit loads and stores *work in practice* on every single ARM device Apple has ever manufactured. I'm not a hardware person, but

...into the reload. > > The code I'm thinking of is in SelectionDAGISel::ComputeLiveOutVRegInfo For the testcase I'm looking at, ComputeLiveOutVRegInfo does not help because it is called prior to selection when the load is an "any_ext" load. It gets (arbitrarily) selected to LDRB, which zero-extends to 32 bits, but that's too late to affect the live-out info. MachineCSE and MachineSink do not help because the first zero-extend is folded into the load (LDRB), so the redundant zero-extend (UXTB) does not appear to be a CSE. In another case, the zero-extend is also folde...

what do you mean by "more optimal instructions" ? -omer On Wed, Nov 16, 2011 at 1:28 AM, Joe Abbey <jabbey at arxan.com> wrote: > I've done a first pass over the past 6 months of changes and some notable > things stood out: > > * The ARM backend has reworked Set Jump Long Jump EH Lowering. > * The ARM backend includes improved support for Cortex-M > *

Hi Tim, >That C++ function is probably what looks for an FrameIndex node and >has been taught that it can be folded into the load. How do you teach a function that a node can be folded into an instruction? ________________________________ From: Tim Northover <t.p.northover at gmail.com> Sent: Monday, January 21, 2019 11:52 PM To: Josh Sharp Cc: via llvm-dev Subject: Re: [llvm-dev]