search for: mem64

...{ "name": "RSP", "id": 32, "typ": { "imm": 64 } } }, "rexp": { "inte": { "int": "MHg4OjY0" } } } } } }, { "move": { "lvar": { "name": "mem64", "id": 58, "typ": { "mem": { "index_type": { "r64": true }, "element_type": { "r8": true } } } }, "rexp": { "store": { "me...

..."rm" or "rr" ? > Hey Anitha, The VEX.W bit is used to denote operand order. In other words, this bit allows for a memop to be used as either the second or third source operand of an FMA instruction, offering greater flexibility. To conceptualize: VFMADDSD xmm1, xmm2, xmm3/mem64, xmm4 VEX.W == 0 VFMADDSD xmm1, xmm2, xmm3, xmm4/mem64 VEX.W == 1 So, logically, one could create the rr pattern with the VEX.W bit set or not. The MemOp4 flag is a similar mechanism for setting the ModRM byte, indicating that the second and third source operands have been swapped. -Cameron...

Hi, A question from r162999 changes: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86InstrFMA.td?r1=162999&r2=162998&pathrev=162999 For the multiclass "fma4s", why is "mr" not inherited from "VEX_W" and "MemOp4" like those of "rm" or "rr" ? multiclass fma4s< > ... def mr : FMA4<opc, MRMSrcMem, (outs

On Tue, Jul 30, 2019 at 12:12:54PM -0700, Thomas Garnier wrote: > if PIE is enabled, switch the paravirt assembly constraints to be > compatible. The %c/i constrains generate smaller code so is kept by > default. > > Position Independent Executable (PIE) support will allow to extend the > KASLR randomization range below 0xffffffff80000000. > > Signed-off-by: Thomas

On Tue, Jul 30, 2019 at 12:12:54PM -0700, Thomas Garnier wrote: > if PIE is enabled, switch the paravirt assembly constraints to be > compatible. The %c/i constrains generate smaller code so is kept by > default. > > Position Independent Executable (PIE) support will allow to extend the > KASLR randomization range below 0xffffffff80000000. > > Signed-off-by: Thomas

...add an additional nop to the call > > + * instruction to ensure patching is possible. > > + */ > > +#define PARAVIRT_CALL_POST "nop;" > > I'm confused; where does the 7 come from? The relative call is 6 bytes, Well, before it, the relative CALL is a CALL reg/mem64, i.e. the target is mem64. For example: ffffffff81025c45: ff 14 25 68 37 02 82 callq *0xffffffff82023768 That address there is practically pv_ops + offset. Now, in the opcode bytes you have 0xff opcode, ModRM byte 0x14 and SIB byte 0x25, and 4 bytes imm32 offset. And this is 7 bytes....

...gt; Hey Anitha, > > The VEX.W bit is used to denote operand order. In other words, this bit > allows for a memop to be used as either the second or third source operand > of an FMA instruction, offering greater flexibility. > > To conceptualize: > > VFMADDSD xmm1, xmm2, xmm3/mem64, xmm4 VEX.W == 0 > VFMADDSD xmm1, xmm2, xmm3, xmm4/mem64 VEX.W == 1 > > So, logically, one could create the rr pattern with the VEX.W bit set or > not. > I actually have confusion in mapping the role of vex_w during instruction selection. For the moment, lets just consider vex_w...

..."a" +#define paravirt_opptr_type "p" + +/* + * Alternative patching requires a maximum of 7 bytes but the relative call is + * only 6 bytes. If PIE is enabled, add an additional nop to the call + * instruction to ensure patching is possible. + * + * Without PIE, the call is reg/mem64: + * ff 14 25 68 37 02 82 callq *0xffffffff82023768 + * + * With PIE, it is relative to %rip and take 1-less byte: + * ff 15 fa d9 ff 00 callq *0xffd9fa(%rip) # <pv_ops+0x30> + * + */ +#define PARAVIRT_CALL_POST "nop;" +#else +#define paravirt_opptr_call "c" +#...

...X:AX/[mem16] = AX,DX "div{w}\t$src", [], IIC_DIV16>, OpSize; let Defs = [EAX,EDX,EFLAGS], Uses = [EAX,EDX] in // EDX:EAX/[mem32] = EAX,EDX def DIV32m : I<0xF7, MRM6m, (outs), (ins i32mem:$src), "div{l}\t$src", [], IIC_DIV32>; // RDX:RAX/[mem64] = RAX,RDX let Defs = [RAX,RDX,EFLAGS], Uses = [RAX,RDX] in def DIV64m : RI<0xF7, MRM6m, (outs), (ins i64mem:$src), "div{q}\t$src", [], IIC_DIV64>; } It is a complete coincidence that these instructions happen to be missing neverHasSideEffects = 1 ;) Often, you can...

On Aug 21, 2012, at 2:02 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > All, > > TableGen likes to infer the MCID::UnmodeledSideEffects flag from an instruction's pattern. When an instruction doesn't have a pattern, it is assumed to have side effects. Hi Jakob, I don't understand what you're saying. Are you proposing that all properties (may load,

Minor changes based on feedback and rebase from v9. Splitting the previous serie in two. This part contains assembly code changes required for PIE but without any direct dependencies with the rest of the patchset. Changes: - patch v10 (assembly): - Swap rax for rdx on entry/64 changes based on feedback. - Addressed feedback from Borislav Petkov on boot, paravirt, alternatives and

Minor changes based on feedback and rebase from v9. Splitting the previous serie in two. This part contains assembly code changes required for PIE but without any direct dependencies with the rest of the patchset. Changes: - patch v10 (assembly): - Swap rax for rdx on entry/64 changes based on feedback. - Addressed feedback from Borislav Petkov on boot, paravirt, alternatives and

...t; "div{w}\t$src", [], IIC_DIV16>, OpSize; > let Defs = [EAX,EDX,EFLAGS], Uses = [EAX,EDX] in // EDX:EAX/[mem32] = EAX,EDX > def DIV32m : I<0xF7, MRM6m, (outs), (ins i32mem:$src), > "div{l}\t$src", [], IIC_DIV32>; > // RDX:RAX/[mem64] = RAX,RDX > let Defs = [RAX,RDX,EFLAGS], Uses = [RAX,RDX] in > def DIV64m : RI<0xF7, MRM6m, (outs), (ins i64mem:$src), > "div{q}\t$src", [], IIC_DIV64>; > } > > It is a complete coincidence that these instructions happen to be missing neverHasSideE...

All, TableGen likes to infer the MCID::UnmodeledSideEffects flag from an instruction's pattern. When an instruction doesn't have a pattern, it is assumed to have side effects. It's possible to override this behavior by setting neverHasSideEffects = 1. It was originally the intention that most instructions have patterns, but that's not the way it worked out. It is often more

...00] efi: mem61: type=4, attr=0xf, range=[0x0000000001f7c000-0x0000000001f7e000) (0MB) [ 0.000000] efi: mem62: type=3, attr=0xf, range=[0x0000000001f7e000-0x0000000001f80000) (0MB) [ 0.000000] efi: mem63: type=4, attr=0xf, range=[0x0000000001f80000-0x0000000001f81000) (0MB) [ 0.000000] efi: mem64: type=3, attr=0xf, range=[0x0000000001f81000-0x0000000001f82000) (0MB) [ 0.000000] efi: mem65: type=4, attr=0xf, range=[0x0000000001f82000-0x0000000001f8c000) (0MB) [ 0.000000] efi: mem66: type=3, attr=0xf, range=[0x0000000001f8c000-0x0000000001f90000) (0MB) [ 0.000000] efi: mem67: type=4,...