search for: adcq

Is there an existing option in X86_64 target code generator to emit a loop for the following code: define i4096 @add(i4096 %a, i4096 %b) alwaysinline { %c = add i4096 %a, %b ret i4096 %c } instead of: movq %rdi, %rax addq 96(%rsp), %rsi adcq 104(%rsp), %rdx movq %rdx, 8(%rdi) movq %rsi, (%rdi) adcq 112(%rsp), %rcx movq %rcx, 16(%rdi) adcq 120(%rsp), %r8 movq %r8, 24(%rdi) adcq 128(%rsp), %r9 movq %r9, 32(%rdi) movq 8(%rsp), %rcx adcq 136(%rsp), %rcx movq %rcx, 40(%rdi) movq 16...

...integer support. (2) Is there a way to convince LLVM's register allocator to do the right thing on x86? I'm getting swaths of code like: movq 88(%rsp), %rax mulq 112(%rsp) movq %rax, %r15 addq %r11, %r15 movq %rdx, %r14 adcq %rcx, %r14 adcq $0, %r9 (that's a 64x64 -> 128-bit multiply with 192-bit accumulate.) The problem is, %r11 and %rcx are dead here. It should have just added %rax and %rdx into them. This results in more movs, more spills, more code and less performance. (3) Is there a w...

...; > > .LBB1_7:                                # %bb.i >                                        #   Parent Loop BB1_6 Depth=1 >                                        # =>  This Inner Loop Header: Depth=2 >        addq    (%rbx,%rsi,8), %rdi >        movl    $0, %r8d >        adcq    $0, %r8 >        addq    (%r14,%rsi,8), %rdi >        adcq    $0, %r8 >        movq    %rdi, (%r15,%rsi,8) >        incq    %rsi >        cmpq    $1000, %rsi             # imm = 0x3E8 >        movq    %r8, %rdi >        jne     .LBB1_7 > > So it basically tries to keep...

...). Indeed, this compiles to: .LBB1_7: # %bb.i # Parent Loop BB1_6 Depth=1 # => This Inner Loop Header: Depth=2 addq (%rbx,%rsi,8), %rdi movl $0, %r8d adcq $0, %r8 addq (%r14,%rsi,8), %rdi adcq $0, %r8 movq %rdi, (%r15,%rsi,8) incq %rsi cmpq $1000, %rsi # imm = 0x3E8 movq %r8, %rdi jne .LBB1_7 So it basically tries to keep track of the carry in %r8 instead of...

...# %bb.i >> # Parent Loop BB1_6 Depth=1 >> # => This Inner Loop Header: Depth=2 >> addq (%rbx,%rsi,8), %rdi >> movl $0, %r8d >> adcq $0, %r8 >> addq (%r14,%rsi,8), %rdi >> adcq $0, %r8 >> movq %rdi, (%r15,%rsi,8) >> incq %rsi >> cmpq $1000, %rsi # imm = 0x3E8 >> movq %r8, %rdi >> jne .LBB1_7 >> &...

...           # %bb.i >>>                                        #   Parent Loop BB1_6 Depth=1 >>>                                        # =>  This Inner Loop Header: Depth=2 >>>        addq    (%rbx,%rsi,8), %rdi >>>        movl    $0, %r8d >>>        adcq    $0, %r8 >>>        addq    (%r14,%rsi,8), %rdi >>>        adcq    $0, %r8 >>>        movq    %rdi, (%r15,%rsi,8) >>>        incq    %rsi >>>        cmpq    $1000, %rsi             # imm = 0x3E8 >>>        movq    %r8, %rdi >>>      ...

Hi all, opt and opt + llc generate the difference aarch64 asm code for the following LLVM code. Is it intended behavior? I expected (A) because I cast %p from i192* to i64*. The information is dropped by opt and 8-byte padding is inserted or I write a bad code? % cat a.ll define void @store0_to_p4(i192* %p) { %p1 = bitcast i192* %p to i64* %p2 = getelementptr i64, i64* %p1, i64 3 %p3 =

On Fri, Jun 11, 2010 at 3:28 PM, Bill Hart <goodwillhart at googlemail.com> wrote: > Hi Eli, > > On 11 June 2010 22:44, Eli Friedman <eli.friedman at gmail.com> wrote: >> On Fri, Jun 11, 2010 at 10:37 AM, Bill Hart <goodwillhart at googlemail.com> wrote: >>> a) What plans are there to support addition, subtraction, >>> multiplication, division,

Hi all, After searching for a decent compiler backend for ages (google sometimes isn't helpful), I recently stumbled upon LLVM. Woot!! I work on bignum arithmetic (I'm a professional mathematician) and have recently decided to switch from developing GPL'd bignum code to BSD licensed code. (See http://www.mpir.org/ which I contributed to for a while - a fork of GMP). Please bear with