search for: armarm

...disassembly output. I have two bytes in question: 4e5f lldb (via the llvm's LLVMARMCodeGen) is providing the following mnemonics: ldr r6, #380, However the value for ldr is "an 8-bit value that is multiplied by 4 and added to the value of the PC to form the memory address" (via ARMARM), so that the correct mnemonics is: ldr r6, [pc, #380] (provided by Apple's otool). I've traced the issue down to ARMInstrThumb.td: // A8.6.57 & A8.6.60 defm tLDR : thumb_ld_rr_ri_enc<0b100, 0b0110, t_addrmode_rrs4, t_addrmode_is4, AddrModeT1_...

...ill work on cortex-m3, but not m0). The list of > them is pretty small though IIRC, so maybe you can write a script that > disassembles & checks for them. Cortex-M0 implements the v6m architecture. Cortex-M3 implements the v7m architecture. Having had a quick look at the v6m and the v7m ARMARM's, next to the extra instructions v7m supports, I think the main other difference that's very relevant for a code generator is that v6m always generates a fault when an unaligned access occurs, whereas v7m can support unaligned accesses for many of the load and store instructions. I think i...

...is bitpattern decodes to a BFI with an invalid mask operand, which is unpredictable. The first example fails with an abort when they are turned on, and otherwise creates the instruction BFI r0, r0, #32, #-32. The second example does not abort and decodes to BFI r0, r0, #1, #2 (0xe7c20090). The ARMARM could be clearer on this point, but the real UAL should be BFI r0, r0, #lsbit #(msbit+1-lsbit) or BFI r0, r0, #3, #-2 In my opinion, the root cause of the problem is that BFI MCInsts store the mask as a 32-bit operand and converts to and from the msbit and lsbit fields during encode, decode, asse...

...t; If you mean that the LDNP > > could start executing with the value of X0 from before the LDR, e.g. > initially X0=0x100, the LDR loads > > X0=0x200 but the LDNP uses the old value of X0=0x100, then I don’t think > that’s true. According to > > section C3.2.4 of the ARMv8 ARMARM *other* observers may observe the LDR > and the LDNP in the wrong > > order, but the CPU executing the instructions will observe them in program > order. > I haven't touched ARMv8 in a few years so I'm rusty on the non-temporal details for that ISA. I lifted this example fro...

Hello, fencing enthusiasts! *TL;DR:* We'd like to propose an addition to the LLVM memory model requiring non-temporal accesses be surrounded by non-temporal load barriers and non-temporal store barriers, and we'd like to add such orderings to the fence IR opcode. We are open to different approaches, hence this email instead of a patch. *Who's "we"?* Philip Reames brought