search for: sxtw

...does a fair bit of work to help make these things work out well. It could probably be generalized for non-AArch64 targets as per the comment in the file header. > On Jun 26, 2014, at 10:42 AM, Sanjay Patel <spatel at rotateright.com> wrote: > > Cool HW trick. :) > Are those 'sxtw' ops free? > That’ll depend on the details of the micro architecture. I don’t know what is typical. > I have to look at the HW manuals again, but I don't think x86-64 has that capability. > > > On Thu, Jun 26, 2014 at 11:23 AM, James Molloy <james.molloy at arm.com&g...

...l stp x24, x23, [sp, #160] // 8-byte Folded Spill stp x22, x21, [sp, #176] // 8-byte Folded Spill stp x20, x19, [sp, #192] // 8-byte Folded Spill stp x29, x30, [sp, #208] // 8-byte Folded Spill ldrsw x8, [x0, #4424] sxtw x10, w2 <------------- w2 is the use of spilled value before spill. sxtw x12, w1 madd x8, x8, x10, x12 ldr x9, [x0, #8] add x9, x9, x8, lsl #2 ldrh w11, [x9] ldrh w10, [x0, #16] str x2,...

...ch64 we get the rather spiffy: _Z3fooPii: // @_Z3fooPii // BB#0: // %entry add w8, w1, #1 // =1 add w9, w1, #2 // =2 ldr w8, [x0, w8, sxtw #2] ldr w9, [x0, w9, sxtw #2] add w8, w9, w8 str w8, [x0, w1, sxtw #2] ret The sext can be matched as part of the addressing mode for AArch64 – maybe it’s something in codegenprepare for x86 going awr...

...te Folded Spill > > stp x22, x21, [sp, #176] // 8-byte Folded Spill > > stp x20, x19, [sp, #192] // 8-byte Folded Spill > > stp x29, x30, [sp, #208] // 8-byte Folded Spill > > ldrsw x8, [x0, #4424] > > sxtw x10, w2 <------------- w2 is the > use of spilled value before spill. > > sxtw x12, w1 > > madd x8, x8, x10, x12 > > ldr x9, [x0, #8] > > add x9, x9, x8, lsl #2 > > ldrh w11, [x9...

...l stp x24, x23, [sp, #160] // 8-byte Folded Spill stp x22, x21, [sp, #176] // 8-byte Folded Spill stp x20, x19, [sp, #192] // 8-byte Folded Spill stp x29, x30, [sp, #208] // 8-byte Folded Spill ldrsw x8, [x0, #4424] sxtw x10, w2 <------------- w2 is the use of spilled value before spill. sxtw x12, w1 madd x8, x8, x10, x12 ldr x9, [x0, #8] add x9, x9, x8, lsl #2 ldrh w11, [x9] ldrh w10, [x0, #16] str x2,...

...tp x22, x21, [sp, #176] // 8-byte Folded Spill > > > > stp x20, x19, [sp, #192] // 8-byte Folded Spill > > > > stp x29, x30, [sp, #208] // 8-byte Folded Spill > > > > ldrsw x8, [x0, #4424] > > > > sxtw x10, w2 <------------- w2 is the > > use of spilled value before spill. > > > > sxtw x12, w1 > > > > madd x8, x8, x10, x12 > > > > ldr x9, [x0, #8] > > > > add x9, x9, x8, l...

...8.5a+memtag -fsanitize=memtag test.cpp -S -o test.s main: // @main .Lmain$local: // %bb.0: // %entry adrp x8, global_array add x8, x8, :lo12:global_array str wzr, [x8, #4] add x8, x8, w0, sxtw #2 ldr w0, [x8, #64] ret .Lfunc_end0: .size main, .Lfunc_end0-main -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200715/568346a0/attachment.html>

...s in an ILP32 scenario, both stemming from the fact that all AArch64 addressing modes do 64-bit arithmetic (unlike amd64, which can be told to do 32-bit arithmetic). For the non-experts, AArch64 allows calculations like these to appear in loads and stores: [x0, x1] == (add x0, x1) [x0, w1, sxtw] == (add x0, (sext w1)) [x0, w1, uxtw] == (add x0, (zext w1)) [x0, w1, sxtw #3] == (add x0, (shl (sext w1), 3)) Plus some more shift modes that are even less relevant here. The second is particularly important for arm64_32 since it mirrors GEP semantics. The first issue is that nothin...

...8.5a+memtag -fsanitize=memtag test.cpp -S -o test.s main: // @main .Lmain$local: // %bb.0: // %entry adrp x8, global_array add x8, x8, :lo12:global_array str wzr, [x8, #4] add x8, x8, w0, sxtw #2 ldr w0, [x8, #64] ret .Lfunc_end0: .size main, .Lfunc_end0-main _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev...

...i32* %StoredAddr %cmp = icmp sgt i64 %K, 1 br i1 %cmp, label %for.body, label %for.end for.end: ret void } # Output in AArch64 where you can see redundant add instructions for stored value, store address, and in cmp : foo: .cfi_startproc // BB#0: cmp w0, #2 b.lt .LBB0_3 // BB#1: sxtw x9, w0 add w8, w0, #1 .LBB0_2: add x10, x1, x9, lsl #2 add x9, x9, #1 str w8, [x10, #4] add w8, w8, #1 cmp x9, #1 b.gt .LBB0_2 .LBB0_3: ret

....body, label %for.end > > for.end: > ret void > } > > > # Output in AArch64 where you can see redundant add instructions for stored value, store address, and in cmp : > > foo: > .cfi_startproc > // BB#0: > cmp w0, #2 > b.lt .LBB0_3 > // BB#1: > sxtw x9, w0 > add w8, w0, #1 > .LBB0_2: > add x10, x1, x9, lsl #2 > add x9, x9, #1 > str w8, [x10, #4] > add w8, w8, #1 > cmp x9, #1 > b.gt .LBB0_2 > .LBB0_3: > ret > _______________________________________________ > LLVM Developers mailing list > llvm-dev...

HI James, Thanks for your reply and hints on what can be done for the Aarch64 backend optimization for llvm We have SPEC license and v8 hardware. So I will start looking into it warm regards Manjunath On Wed, Jun 25, 2014 at 8:42 PM, James Molloy <james.molloy at arm.com> wrote: > Hi Manjunath, > > At the time of writing that status we had only done our initial analysis. >

...// @main* > > *.Lmain$local:* > > *// %bb.0: // %entry* > > * adrp x8, global_array* > > * add x8, x8, :lo12:global_array* > > * str wzr, [x8, #4]* > > * add x8, x8, w0, sxtw #2* > > * ldr w0, [x8, #64]* > > * ret* > > *.Lfunc_end0:* > > * .size main, .Lfunc_end0-main* > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists....