search for: movabsq

Displaying 20 results from an estimated 60 matches for "movabsq".

2016 May 13
4
RFC: callee saved register verifier
...his: before every call store a cookie in all the registers that the call is supposed to preserve, and after the call returns, assert that the supposedly callee saved registers weren't clobbered. So for a call target that respects the C calling convention, we'll generate something like: movabsq $0xCA5FCA5FCA5FCA5F, %rbp movabsq $0xCA5FCA5FCA5FCA5F, %rbx # can also be movq %rbp, %rbx etc. movabsq $0xCA5FCA5FCA5FCA5F, %r12 movabsq $0xCA5FCA5FCA5FCA5F, %r13 movabsq $0xCA5FCA5FCA5FCA5F, %r14 movabsq $0xCA5FCA5FCA5FCA5F, %r15 callq foo movabsq $0xCA5FCA5FCA5FCA5F, %rax...
2016 May 13
2
RFC: callee saved register verifier
...; registers that the call is supposed to preserve, and after the call > > returns, assert that the supposedly callee saved registers weren't > > clobbered. So for a call target that respects the C calling > > convention, we'll generate something like: > > > > movabsq $0xCA5FCA5FCA5FCA5F, %rbp > > movabsq $0xCA5FCA5FCA5FCA5F, %rbx # can also be movq %rbp, %rbx etc. > > movabsq $0xCA5FCA5FCA5FCA5F, %r12 > > movabsq $0xCA5FCA5FCA5FCA5F, %r13 > > movabsq $0xCA5FCA5FCA5FCA5F, %r14 > > movabsq $0xCA5FCA5FCA5FCA5F, %r15 > > c...
2016 May 06
3
Unnecessary spill/fill issue
...that computes a series of constant vectors at compile time. Each vector has a single use. In the final asm, I see a series of spills at the top of the function of all the constant vectors immediately to stack, then each use references the stack pointer directly: Lots of these at top of function: movabsq $.LCPI0_212, %rbx vmovaps (%rbx), %ymm0 vmovaps %ymm0, 2816(%rsp) # 32-byte Spill Later on, each use references the stack pointer: vpaddd 2816(%rsp), %ymm4, %ymm1 # 32-byte Folded Reload It seems the spill to stack is unnecessary. In one particularly bad kernel, I have 128 8-wide constant...
2013 Nov 06
2
[LLVMdev] "-relocation-model=static" does not work in llc compiler ?
> If you also give "-code-model=large" then LLVM won't assume that > "addr" is nearby so it'll use a movabsq with a static relocation. Actually, it seems our own Eli has written rather a good description of these code models: http://eli.thegreenplace.net/2012/01/03/understanding-the-x64-code-models/. Well worth the read (the default models he talks about at the top are essentially "static")....
2013 Nov 06
0
[LLVMdev] "-relocation-model=static" does not work in llc compiler ?
Yep. I tried it. It used a movabsq instruction instead and a static allocation. Thanks a lot. I will read it immediately. Again thanks. - Pengcheng On Nov 6, 2013, at 1:45 PM, Tim Northover <t.p.northover at gmail.com> wrote: >> If you also give "-code-model=large" then LLVM won't assume that >&gt...
2016 Oct 27
1
PIC and mcmodel=large on x86 doesn't use any relocations
...-S -fPIC -mcmodel=large'): DataLoadAndStore: # @DataLoadAndStore .cfi_startproc # BB#0: pushq %rbp .Ltmp0: .cfi_def_cfa_offset 16 .Ltmp1: .cfi_offset %rbp, -16 movq %rsp, %rbp .Ltmp2: .cfi_def_cfa_register %rbp movabsq $src, %rax movl (%rax), %ecx movabsq $dst, %rdx movl %ecx, (%rdx) movabsq $dptr, %rsi movq %rdx, (%rsi) movl (%rax), %ecx movl %ecx, (%rdx) movl (%rax), %ecx movq (%rsi), %rax movl %ecx, (%rax)...
2016 May 04
2
OrcLazyJIT for windows
...// 0x16: pushq %r14 0x41, 0x57, // 0x18: pushq %r15 0x48, 0x81, 0xec, 0x08, 0x02, 0x00, 0x00, // 0x1a: subq 0x208, %rsp 0x48, 0x0f, 0xae, 0x04, 0x24, // 0x21: fxsave64 (%rsp) 0x48, 0xb9, // 0x26: movabsq <CBMgr>, %rcx // 0x28: Callback manager addr. 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x48, 0x8B, 0x55, 0x08, // mov rdx,QWORD PTR [rbp+0x8] 0x48, 0x83, 0xea, 0x06, // sub rdx,0x6 0x48, 0xb8, // 0x38...
2013 Jun 25
2
[LLVMdev] Contants generation
Hi again, Actually, I've just been looking at the existing code and the ARM solution may be over-complicated for this situation. You should be able to override EmitConstantPool directly, or possibly even just override getSectionForConstantKind in X86LinuxTargetObjectFile (and perhaps others) to return .text. Tim.
2013 Jun 25
0
[LLVMdev] Contants generation
That what I actually did now, locally in the code. But I still see the " movabsq" .text .align 8, 0x90 .LCPI0_0: .quad 4606281698874543309 # double 0.9 .LCPI0_1: .quad 4631147119616759172 # double 42.2794408 .LCPI0_2: .long 1065353216 # float 1 .zero 4 ... movabsq $.LCPI0_1, %rax # encoding: [0x48,0xb8,A,A,A,A,A,A,A,A]...
2013 Nov 06
1
[LLVMdev] "-relocation-model=static" does not work in llc compiler ?
...tion-model=pic (!!!!!note changed), it still generate the static relocation. So does it mean -relocation-model=pic does not like to work with -code-model=large ? Thanks, -Pengcheng On Nov 6, 2013, at 1:52 PM, lipengcheng <pli at cs.rochester.edu> wrote: > Yep. I tried it. It used a movabsq instruction instead and a static allocation. > Thanks a lot. > > I will read it immediately. Again thanks. > > - Pengcheng > > On Nov 6, 2013, at 1:45 PM, Tim Northover <t.p.northover at gmail.com> wrote: > >>> If you also give "-code-model=large&q...
2016 May 04
2
OrcLazyJIT for windows
...// 0x18: pushq %r15 >> >> 0x48, 0x81, 0xec, 0x08, 0x02, 0x00, 0x00, // 0x1a: subq 0x208, %rsp >> >> 0x48, 0x0f, 0xae, 0x04, 0x24, // 0x21: fxsave64 (%rsp) >> >> >> >> 0x48, 0xb9, // 0x26: movabsq <CBMgr>, %rcx >> >> // 0x28: Callback manager addr. >> >> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >> >> >> >> 0x48, 0x8B, 0x55, 0x08, // mov rdx,QWORD PTR [rbp+0x8] >> >> 0x48, 0x83, 0xea, 0x06,...
2013 Aug 20
0
[LLVMdev] Memory optimizations for LLVM JIT
...x) p->a[4] = p->a[2]; mov %rdx,0x20(%rax) p->a[5] = p->a[4]; mov %rdx,0x28(%rax) -------------------------------------------------------------------- JIT (map p to GlobalVariable) ==> JIT (map p to constant GlobalVariable) 1* movabsq $0x18c6b88, %rax 1* movabsq $0x18c6b88, %rax 2* movq (%rax), %rcx // p 2* movq (%rax), %rax 3* movq 0x8(%rcx), %rdx // a[1] 3* movq 0x8(%rax), %rcx 4* movq %rdx, 0x10(%rcx) // a[2] 4* movq %rcx, 0x10(%rax) 5 movq (%rax), %rcx...
2010 Jul 08
1
[LLVMdev] simple way to print disassembly of final code from jit?
Thanks for all the hints everyone. Based on your suggestion, O.J., I've added code to toy.cpp from the tutorial to disassemble. ready> 1+1; ready> movabsq $140737353367568, %rax movsd (%rax), %xmm0 ret Evaluated to 2.000000 ready> Which looks correct by inspection - printing the byte array to stdout and feeding it to llvm-mc offline produces the same code as one would also expect. echo '0x48 0xb8 0x10 0x40 0xf4 0xf7 0xff 0x7f 0x0 0x0 0xf2...
2013 Aug 20
4
[LLVMdev] Memory optimizations for LLVM JIT
...x) p->a[4] = p->a[2]; mov %rdx,0x20(%rax) p->a[5] = p->a[4]; mov %rdx,0x28(%rax) -------------------------------------------------------------------- JIT (map p to GlobalVariable) ==> JIT (map p to constant GlobalVariable) 1* movabsq $0x18c6b88, %rax 1* movabsq $0x18c6b88, %rax 2* movq (%rax), %rcx // p 2* movq (%rax), %rax 3* movq 0x8(%rcx), %rdx // a[1] 3* movq 0x8(%rax), %rcx 4* movq %rdx, 0x10(%rcx) // a[2] 4* movq %rcx, 0x10(%rax) 5 movq (%rax), %rcx...
2017 Apr 19
3
[cfe-dev] FE_INEXACT being set for an exact conversion from float to unsigned long long
...rget/X86//README-X86-64.txt > … > Are we better off using branches instead of cmove to implement FP to > unsigned i64? > > _conv: > ucomiss LC0(%rip), %xmm0 > cvttss2siq %xmm0, %rdx > jb L3 > subss LC0(%rip), %xmm0 > movabsq $-9223372036854775808, %rax > cvttss2siq %xmm0, %rdx > xorq %rax, %rdx > L3: > movq %rdx, %rax > ret > > instead of > > _conv: > movss LCPI1_0(%rip), %xmm1 > cvttss2siq %xmm0, %rcx > movaps %xmm...
2011 Sep 26
3
[LLVMdev] x86-64 large stack offsets
...'s just a matter of changing a few variable types in LLVM from unsigned to uint64_t in the functions that calculate the stack offsets. The real trouble I'm having is finding a good place to break up the displacements during lowering. I would like the offset to be calculated similar to gcc: movabsq $-4294969640, %rdx movsd 0(%rbp,%rdx), %xmm0 Any suggestions on the correct lowering pass to do a transformation like this? I'm an LLVM noob, so I'm not sure where it should go. Tx, Cameron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://list...
2015 Jul 24
2
[LLVMdev] SIMD for sdiv <2 x i64>
...these instructions? Thanks. %sub.ptr.sub.i6.i.i.i.i = sub <2 x i64> %sub.ptr.lhs.cast.i4.i.i.i.i, %sub.ptr.rhs.cast.i5.i.i.i.i %sub.ptr.div.i7.i.i.i.i = sdiv <2 x i64> %sub.ptr.sub.i6.i.i.i.i, <i64 24, i64 24> Assembly: vpsubq %xmm6, %xmm5, %xmm5 vmovq %xmm5, %rax movabsq $3074457345618258603, %rbx # imm = 0x2AAAAAAAAAAAAAAB imulq %rbx movq %rdx, %rcx movq %rcx, %rax shrq $63, %rax shrq $2, %rcx addl %eax, %ecx vpextrq $1, %xmm5, %rax imulq %rbx movq %rdx, %rax shrq $63, %rax shrq $2, %rd...
2013 Aug 02
2
[LLVMdev] Missing optimization - constant parameter
...; uint64_t val, *p; extern uint64_t xtr( uint64_t); uint64_t caller() { uint64_t x; p = &val; x = 12345123400L; *p = x; return xtr(x); } clang (3.2, 3.3 and svn) generates the following X86 code (at -O3): caller: movq $val, p(%rip) movabsq $12345123400, %rax # imm = 0x2DFD3A248 movq %rax, val(%rip) movabsq $12345123400, %rdi # imm = 0x2DFD3A248 jmp xtr # TAILCALL Notice that the constant value is loaded twice, once into %rax and again into %rdi as the first parameter for...
2013 Nov 06
2
[LLVMdev] "-relocation-model=static" does not work in llc compiler ?
Hi LLVM, When I compile code using llc with options " -relocation-model=static", the generated code still has relative addressing using *rip* frame pointer. May I know how to get rid of frame pointer and totally using absolute addressing ? E.g. callq *addr(%rip). Here *addr* is a global variable, and I want the global address shows up here, instead of relative addressing.
2013 Nov 06
0
[LLVMdev] "-relocation-model=static" does not work in llc compiler ?
...del in x86-64 guarantees that all code and data will be in the low 2GB of the address space so it's more efficient for the compiler to use PC-relative addressing anyway. If you also give "-code-model=large" then LLVM won't assume that "addr" is nearby so it'll use a movabsq with a static relocation. Cheers. Tim.