search for: lo12

...rmv8-a+fp+simd .file "test.cpp" .text .align 2 .global _Z3fooii .type _Z3fooii, %function _Z3fooii: .LFB0: .cfi_startproc cbz w0, .L1 adrp x6, globalvar add w5, w0, w0, lsr 31 ldr w3, [x6,#:lo12:globalvar] <== hoist load of globalvar mov w2, 0 asr w5, w5, 1 .L4: cmp w5, w2 add w2, w2, w1 add w4, w3, w1 csel w3, w4, w3, hi cmp w2, w0 bcc .L4 str w3, [x6,#:lo12:globalvar] <==...

...2 >> .global _Z3fooii >> .type _Z3fooii, %function >> _Z3fooii: >> .LFB0: >> .cfi_startproc >> cbz w0, .L1 >> adrp x6, globalvar >> add w5, w0, w0, lsr 31 >> ldr w3, [x6,#:lo12:globalvar] <== hoist load of globalvar >> mov w2, 0 >> asr w5, w5, 1 >> .L4: >> cmp w5, w2 >> add w2, w2, w1 >> add w4, w3, w1 >> csel w3, w4, w3, hi >>...

...rmv8-a+fp+simd         .file   "test.cpp"         .text         .align  2         .global _Z3fooii         .type   _Z3fooii, %function _Z3fooii: .LFB0:         .cfi_startproc         cbz     w0, .L1         adrp    x6, globalvar         add     w5, w0, w0, lsr 31         ldr     w3, [x6,#:lo12:globalvar]                        <== hoist load of globalvar         mov     w2, 0         asr     w5, w5, 1 .L4:         cmp     w5, w2         add     w2, w2, w1         add     w4, w3, w1         csel    w3, w4, w3, hi         cmp     w2, w0         bcc     .L4         str     w3, [x6,#:lo12...

Sorry, quick message to ignore what I wrote before, I got myself confused (probably you too), With a recent trunk build I get this: f: adrp x8, g ldr x8, [x8, :lo12:g] mov w2, #16 mov x1, x0 mov x0, x8 b memcmp This looks more correct, and I need to look a bit more into this (and how clang 10.0.0 behaves). ________________________________ From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of...

...cmp(g, c, 16); } $ clang --target=aarch64-linux-gnu -Os -mstrict-align -S test.c $ cat test.s .text .file "test.c" .globl f // -- Begin function f .p2align 2 .type f, at function f: // @f // %bb.0: adrp x8, g ldr x10, [x8, :lo12:g] ldr x9, [x0] ldr x8, [x10] rev x9, x9 rev x8, x8 cmp x8, x9 b.ne .LBB0_3 // %bb.1: ldr x8, [x10, #8] ldr x9, [x0, #8] rev x8, x8 rev x9, x9 cmp x8, x9 b.ne .LBB0_3 // %bb.2: mov w0, wzr ret .LBB0_3: cmp x8, x9 mov w8, #-1 cneg w0, w8, hs ret .Lfunc_end0: .size f, .Lfunc_end0-f...

...array[argc + 16]; // BOOM } clang++ -O1 --target=aarch64-linux -march=armv8.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/...

...> b) Hidden Symbols (static int g; or -fvisibility=hidden) > > Materialization of hidden symbols now fetch and insert the memory tag > via. `ldg`. On aarch64, this means non PC-relative > loads/stores/address-taken (*g = 7;) generates: > > adrp x0, g; > > ldg x0, [x0, :lo12:g]; // new instruction > > mov x1, #7; > > str x1, [x0, :lo12:g]; > > Does the tagging of these hidden symbols only protect against RW > primitives without a similar ldg? If I knew the address of the hidden > symbol I could presumably use the same sequence, but I think I...

...array[argc + 16]; // BOOM } clang++ -O1 --target=aarch64-linux -march=armv8.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...

...n Symbols (static int g; or -fvisibility=hidden) >>> > Materialization of hidden symbols now fetch and insert the memory tag via. `ldg`. On aarch64, this means non PC-relative loads/stores/address-taken (*g = 7;) generates: >>> > adrp x0, g; >>> > ldg x0, [x0, :lo12:g]; // new instruction >>> > mov x1, #7; >>> > str x1, [x0, :lo12:g]; >>> >>> Does the tagging of these hidden symbols only protect against RW >>> primitives without a similar ldg? If I knew the address of the hidden >>> symbol I could p...

...his table and apply random memory tags to each global prior to relocations. 5. Materialization of hidden symbols now fetch and insert the memory tag via. `ldg`. On aarch64, this means non PC-relative loads/stores/address-taken (*g = 7;) generates: adrp x0, g; ldg x0, [x0, :lo12:g]; // new instruction mov x1, #7; str x1, [x0, :lo12:g]; Note that this materialization sequence means that executables built with MTE globals are not able to run on non-MTE hardware. Note: Some dynamic symbols can be transformed at link time into hidden symbols if: 1. Th...

Why did you take out the constant island code for Arm 64? Just did not need it? On 02/21/2013 12:01 PM, Tim Northover wrote: > Hi Reed, > >> I'm wondering if there is already some mechanism where I can assign literals >> to the text section and get a label for where it has been stored. > > I think putting them in the text section is reasonably simple, though >

...rmv8.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* > > > > _________________________________...

...on). > > > 5. > > > > Materialization of hidden symbols now fetch and insert the memory tag > > via. `ldg`. On aarch64, this means non PC-relative > > loads/stores/address-taken (*g = 7;) generates: > > adrp x0, g; > > ldg x0, [x0, :lo12:g]; // new instruction > > mov x1, #7; > > str x1, [x0, :lo12:g]; > > > > Note that this materialization sequence means that executables built > > with MTE globals are not able to run on non-MTE hardware. > > i need to think about this, i think a...

...dl, PtrVT, + DAG.getTargetConstantPool(GV, PtrVT, 0, 0, + AArch64II::MO_NO_FLAG), + DAG.getTargetConstantPool(GV, PtrVT, 0, 0, + AArch64II::MO_LO12), + DAG.getConstant(8, MVT::i32)); + SDValue GlobalAddr = DAG.getLoad(PtrVT, dl, DAG.getEntryNode(), PoolAddr, + MachinePointerInfo::getConstantPool(), + /*isVolatile=*/ false, +...

Thanks for reducing that for me! The outliner pulls out the following: OUTLINED_FUNCTION_0: // @OUTLINED_FUNCTION_0 .cfi_sections .debug_frame .cfi_startproc // %bb.0: adrp x29, g1 add x29, x29, :lo12:g1 adrp x30, g2 // This adrp shouldn’t have been outlined. ret It shouldn’t be pulling out that adrp. There’s a special case for arps in the outliner which hinged on the assumption that x30 wouldn’t be used in that way. I just finished writing a fix which I’ll...

Sorry, I was using a modified compiler, which by coincidence made the bug much easier to reproduce. In some rare cases, the compiler will use x30 as a general-purpose register; in that case, outlining breaks because the "ret" branches to the wrong address.  Testcase (reproduce with "clang -O3 --target=aarch64-pc-linux-gnu -mllvm -enable-machine-outliner"): extern long g1;

Hi, I am trying to execute a simple hello world program compiled like so: path/to/compiled/clang -o test --target=aarch64-linux-gnu -march=armv8.5-a -fsanitize=hwaddress --sysroot=/usr/aarch64-linux-gnu/ -L/usr/lib/gcc/aarch64-linux-gnu/10.1.0/ -g test.c However, when I look at the disassembly, there is an unknown instruction listed at 0x2d51c: 000000000002d4c0 main: 2d4c0: ff c3 00 d1

...%wanted, i8 %new) nounwind { ; CHECK-LABEL: test_atomic_cmpxchg_i8: - %old = cmpxchg i8* @var8, i8 %wanted, i8 %new acquire + %old = cmpxchg i8* @var8, i8 %wanted, i8 %new acquire acquire ; CHECK-NOT: dmb ; CHECK: adrp [[TMPADDR:x[0-9]+]], var8 ; CHECK: add x[[ADDR:[0-9]+]], [[TMPADDR]], #:lo12:var8 @@ -920,7 +920,7 @@ define i8 @test_atomic_cmpxchg_i8(i8 %wanted, i8 %new) nounwind { define i16 @test_atomic_cmpxchg_i16(i16 %wanted, i16 %new) nounwind { ; CHECK-LABEL: test_atomic_cmpxchg_i16: - %old = cmpxchg i16* @var16, i16 %wanted, i16 %new seq_cst + %old = cmpxchg i16* @var16,...