maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/X86/mul-i256.ll

283 lines
9.9 KiB
LLVM
Raw Normal View History

Commit full codegen for mul-i256.ll . NFC The full codegen is committed for larger multiply, so that won't make the test suite more fragile. However, it'll allow to expose the effects fo various DAG combine. llvm-svn: 294196
2017-02-07 00:21:41 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
; RUN: llc < %s -mtriple=i386-unknown | FileCheck %s --check-prefix=X32
; RUN: llc < %s -mtriple=x86_64-unknown | FileCheck %s --check-prefix=X64
[SDAG] Add a fallback multiplication expansion LegalizeIntegerTypes does not have a way to expand multiplications for large integer types (i.e. larger than twice the native bit width). There's no standard runtime call to use in that case, and so we'd just assert. Unfortunately, as it turns out, it is possible to hit this case from standard-ish C code in rare cases. A particular case a user ran into yesterday involved an __int128 induction variable and a loop with a quadratic (not linear) recurrence which triggered some backend logic using SCEVExpander. In this case, the BinomialCoefficient code in SCEV generates some i129 variables, which get widened to i256. At a high level, this is not actually good (i.e. the underlying optimization, PPCLoopPreIncPrep, should not be transforming the loop in question for performance reasons), but regardless, the backend shouldn't crash because of cost-modeling issues in the optimizer. This is a straightforward implementation of the multiplication expansion, based on the algorithm in Hacker's Delight. I validated it against the code for the mul256b function from http://locklessinc.com/articles/256bit_arithmetic/ using random inputs. There should be no functional change for previously-working code (the new expansion code only replaces an assert). Fixes PR19797. llvm-svn: 270720
2016-05-26 00:50:22 +08:00
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
define void @test(i256* %a, i256* %b, i256* %out) #0 {
Commit full codegen for mul-i256.ll . NFC The full codegen is committed for larger multiply, so that won't make the test suite more fragile. However, it'll allow to expose the effects fo various DAG combine. llvm-svn: 294196
2017-02-07 00:21:41 +08:00
; X32-LABEL: test:
; X32: # BB#0: # %entry
; X32-NEXT: pushl %ebp
; X32-NEXT: .Lcfi0:
; X32-NEXT: .cfi_def_cfa_offset 8
; X32-NEXT: .Lcfi1:
; X32-NEXT: .cfi_offset %ebp, -8
; X32-NEXT: movl %esp, %ebp
; X32-NEXT: .Lcfi2:
; X32-NEXT: .cfi_def_cfa_register %ebp
; X32-NEXT: pushl %ebx
; X32-NEXT: pushl %edi
; X32-NEXT: pushl %esi
; X32-NEXT: andl $-8, %esp
; X32-NEXT: subl $168, %esp
; X32-NEXT: .Lcfi3:
; X32-NEXT: .cfi_offset %esi, -20
; X32-NEXT: .Lcfi4:
; X32-NEXT: .cfi_offset %edi, -16
; X32-NEXT: .Lcfi5:
; X32-NEXT: .cfi_offset %ebx, -12
; X32-NEXT: movl 8(%ebp), %eax
; X32-NEXT: movl 16(%eax), %ecx
; X32-NEXT: movl %ecx, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl 20(%eax), %ecx
; X32-NEXT: movl %ecx, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl 24(%eax), %ecx
; X32-NEXT: movl %ecx, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl 28(%eax), %ecx
; X32-NEXT: movl %ecx, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl 8(%eax), %ecx
; X32-NEXT: movl %ecx, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl 12(%eax), %ecx
; X32-NEXT: movl %ecx, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl (%eax), %ecx
; X32-NEXT: movl %ecx, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl 4(%eax), %ebx
; X32-NEXT: movl 12(%ebp), %eax
; X32-NEXT: movl 16(%eax), %ecx
; X32-NEXT: movl %ecx, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl 20(%eax), %ecx
; X32-NEXT: movl %ecx, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl 24(%eax), %ecx
; X32-NEXT: movl %ecx, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl 28(%eax), %ecx
; X32-NEXT: movl %ecx, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl (%eax), %ecx
; X32-NEXT: movl %ecx, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl 4(%eax), %ecx
; X32-NEXT: movl %ecx, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl 8(%eax), %esi
; X32-NEXT: movl 12(%eax), %edi
; X32-NEXT: leal {{[0-9]+}}(%esp), %eax
; X32-NEXT: pushl $0
; X32-NEXT: pushl $0
; X32-NEXT: pushl %edi
; X32-NEXT: movl %edi, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: pushl %esi
; X32-NEXT: movl %esi, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: pushl $0
; X32-NEXT: pushl $0
; X32-NEXT: pushl %ebx
; X32-NEXT: pushl {{[0-9]+}}(%esp) # 4-byte Folded Reload
; X32-NEXT: pushl %eax
; X32-NEXT: calll __multi3
; X32-NEXT: addl $32, %esp
; X32-NEXT: leal {{[0-9]+}}(%esp), %eax
; X32-NEXT: pushl $0
; X32-NEXT: pushl $0
; X32-NEXT: pushl %edi
; X32-NEXT: pushl %esi
; X32-NEXT: pushl $0
; X32-NEXT: pushl $0
; X32-NEXT: movl {{[0-9]+}}(%esp), %esi # 4-byte Reload
; X32-NEXT: pushl %esi
; X32-NEXT: movl {{[0-9]+}}(%esp), %edi # 4-byte Reload
; X32-NEXT: pushl %edi
; X32-NEXT: pushl %eax
; X32-NEXT: calll __multi3
; X32-NEXT: addl $32, %esp
; X32-NEXT: leal {{[0-9]+}}(%esp), %eax
; X32-NEXT: pushl $0
; X32-NEXT: pushl $0
; X32-NEXT: pushl {{[0-9]+}}(%esp) # 4-byte Folded Reload
; X32-NEXT: pushl {{[0-9]+}}(%esp) # 4-byte Folded Reload
; X32-NEXT: pushl $0
; X32-NEXT: pushl $0
; X32-NEXT: pushl %ebx
; X32-NEXT: pushl {{[0-9]+}}(%esp) # 4-byte Folded Reload
; X32-NEXT: pushl %eax
; X32-NEXT: calll __multi3
; X32-NEXT: addl $32, %esp
; X32-NEXT: leal {{[0-9]+}}(%esp), %eax
; X32-NEXT: pushl %esi
; X32-NEXT: pushl %edi
; X32-NEXT: pushl %ebx
; X32-NEXT: pushl {{[0-9]+}}(%esp) # 4-byte Folded Reload
; X32-NEXT: pushl {{[0-9]+}}(%esp) # 4-byte Folded Reload
; X32-NEXT: pushl {{[0-9]+}}(%esp) # 4-byte Folded Reload
; X32-NEXT: pushl {{[0-9]+}}(%esp) # 4-byte Folded Reload
; X32-NEXT: pushl {{[0-9]+}}(%esp) # 4-byte Folded Reload
; X32-NEXT: pushl %eax
; X32-NEXT: calll __multi3
; X32-NEXT: addl $32, %esp
; X32-NEXT: leal {{[0-9]+}}(%esp), %eax
; X32-NEXT: pushl $0
; X32-NEXT: pushl $0
; X32-NEXT: pushl {{[0-9]+}}(%esp) # 4-byte Folded Reload
; X32-NEXT: pushl {{[0-9]+}}(%esp) # 4-byte Folded Reload
; X32-NEXT: pushl $0
; X32-NEXT: pushl $0
; X32-NEXT: pushl %esi
; X32-NEXT: pushl %edi
; X32-NEXT: pushl %eax
; X32-NEXT: calll __multi3
; X32-NEXT: addl $32, %esp
; X32-NEXT: movl {{[0-9]+}}(%esp), %eax
; X32-NEXT: movl {{[0-9]+}}(%esp), %ecx
; X32-NEXT: movl {{[0-9]+}}(%esp), %edx
; X32-NEXT: movl {{[0-9]+}}(%esp), %esi
; X32-NEXT: addl {{[0-9]+}}(%esp), %edx
; X32-NEXT: adcl {{[0-9]+}}(%esp), %esi
; X32-NEXT: adcl $0, %ecx
; X32-NEXT: adcl $0, %eax
; X32-NEXT: addl {{[0-9]+}}(%esp), %edx
; X32-NEXT: movl %edx, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: adcl {{[0-9]+}}(%esp), %esi
; X32-NEXT: movl %esi, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl {{[0-9]+}}(%esp), %edi
; X32-NEXT: adcl $0, %edi
; X32-NEXT: movl {{[0-9]+}}(%esp), %ebx
; X32-NEXT: adcl $0, %ebx
; X32-NEXT: addl %ecx, %edi
; X32-NEXT: adcl %eax, %ebx
[DAGCombine] (addcarry 0, 0, X) -> (ext/trunc X) Summary: While this makes some case better and some case worse - so it's unclear if it is a worthy combine just by itself - this is a useful canonicalisation. As per discussion in D32756 . Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32916 llvm-svn: 303441
2017-05-20 02:20:44 +08:00
; X32-NEXT: setb %al
Commit full codegen for mul-i256.ll . NFC The full codegen is committed for larger multiply, so that won't make the test suite more fragile. However, it'll allow to expose the effects fo various DAG combine. llvm-svn: 294196
2017-02-07 00:21:41 +08:00
; X32-NEXT: addl {{[0-9]+}}(%esp), %edi
; X32-NEXT: adcl {{[0-9]+}}(%esp), %ebx
[DAGCombine] (addcarry 0, 0, X) -> (ext/trunc X) Summary: While this makes some case better and some case worse - so it's unclear if it is a worthy combine just by itself - this is a useful canonicalisation. As per discussion in D32756 . Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32916 llvm-svn: 303441
2017-05-20 02:20:44 +08:00
; X32-NEXT: movzbl %al, %eax
Commit full codegen for mul-i256.ll . NFC The full codegen is committed for larger multiply, so that won't make the test suite more fragile. However, it'll allow to expose the effects fo various DAG combine. llvm-svn: 294196
2017-02-07 00:21:41 +08:00
; X32-NEXT: adcl {{[0-9]+}}(%esp), %eax
; X32-NEXT: movl %eax, {{[0-9]+}}(%esp) # 4-byte Spill
[DAGCombine] (addcarry 0, 0, X) -> (ext/trunc X) Summary: While this makes some case better and some case worse - so it's unclear if it is a worthy combine just by itself - this is a useful canonicalisation. As per discussion in D32756 . Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32916 llvm-svn: 303441
2017-05-20 02:20:44 +08:00
; X32-NEXT: movl {{[0-9]+}}(%esp), %eax
; X32-NEXT: adcl $0, %eax
; X32-NEXT: movl %eax, {{[0-9]+}}(%esp) # 4-byte Spill
Commit full codegen for mul-i256.ll . NFC The full codegen is committed for larger multiply, so that won't make the test suite more fragile. However, it'll allow to expose the effects fo various DAG combine. llvm-svn: 294196
2017-02-07 00:21:41 +08:00
; X32-NEXT: leal {{[0-9]+}}(%esp), %eax
; X32-NEXT: pushl {{[0-9]+}}(%esp) # 4-byte Folded Reload
; X32-NEXT: pushl {{[0-9]+}}(%esp) # 4-byte Folded Reload
; X32-NEXT: pushl {{[0-9]+}}(%esp) # 4-byte Folded Reload
; X32-NEXT: pushl {{[0-9]+}}(%esp) # 4-byte Folded Reload
; X32-NEXT: pushl {{[0-9]+}}(%esp) # 4-byte Folded Reload
; X32-NEXT: pushl {{[0-9]+}}(%esp) # 4-byte Folded Reload
; X32-NEXT: pushl {{[0-9]+}}(%esp) # 4-byte Folded Reload
; X32-NEXT: pushl {{[0-9]+}}(%esp) # 4-byte Folded Reload
; X32-NEXT: pushl %eax
; X32-NEXT: calll __multi3
; X32-NEXT: addl $32, %esp
; X32-NEXT: movl {{[0-9]+}}(%esp), %esi
; X32-NEXT: addl {{[0-9]+}}(%esp), %esi
; X32-NEXT: movl {{[0-9]+}}(%esp), %ecx
; X32-NEXT: adcl {{[0-9]+}}(%esp), %ecx
; X32-NEXT: movl {{[0-9]+}}(%esp), %edx
; X32-NEXT: adcl {{[0-9]+}}(%esp), %edx
; X32-NEXT: movl {{[0-9]+}}(%esp), %eax
; X32-NEXT: adcl {{[0-9]+}}(%esp), %eax
; X32-NEXT: addl %edi, %esi
; X32-NEXT: adcl %ebx, %ecx
; X32-NEXT: adcl {{[0-9]+}}(%esp), %edx # 4-byte Folded Reload
; X32-NEXT: adcl {{[0-9]+}}(%esp), %eax # 4-byte Folded Reload
; X32-NEXT: movl {{[0-9]+}}(%esp), %edi
; X32-NEXT: movl %edi, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl {{[0-9]+}}(%esp), %ebx
; X32-NEXT: movl 16(%ebp), %edi
; X32-NEXT: movl %ebx, 4(%edi)
; X32-NEXT: movl 16(%ebp), %ebx
; X32-NEXT: movl {{[0-9]+}}(%esp), %edi # 4-byte Reload
; X32-NEXT: movl %edi, (%ebx)
; X32-NEXT: movl {{[0-9]+}}(%esp), %edi # 4-byte Reload
; X32-NEXT: movl %edi, 8(%ebx)
; X32-NEXT: movl {{[0-9]+}}(%esp), %edi # 4-byte Reload
; X32-NEXT: movl %edi, 12(%ebx)
; X32-NEXT: movl %esi, 16(%ebx)
; X32-NEXT: movl %ecx, 20(%ebx)
; X32-NEXT: movl %edx, 24(%ebx)
; X32-NEXT: movl %eax, 28(%ebx)
; X32-NEXT: leal -12(%ebp), %esp
; X32-NEXT: popl %esi
; X32-NEXT: popl %edi
; X32-NEXT: popl %ebx
; X32-NEXT: popl %ebp
; X32-NEXT: retl
;
; X64-LABEL: test:
; X64: # BB#0: # %entry
; X64-NEXT: pushq %r15
; X64-NEXT: .Lcfi0:
; X64-NEXT: .cfi_def_cfa_offset 16
; X64-NEXT: pushq %r14
; X64-NEXT: .Lcfi1:
; X64-NEXT: .cfi_def_cfa_offset 24
[DAGCombine] (addcarry 0, 0, X) -> (ext/trunc X) Summary: While this makes some case better and some case worse - so it's unclear if it is a worthy combine just by itself - this is a useful canonicalisation. As per discussion in D32756 . Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32916 llvm-svn: 303441
2017-05-20 02:20:44 +08:00
; X64-NEXT: pushq %rbx
Commit full codegen for mul-i256.ll . NFC The full codegen is committed for larger multiply, so that won't make the test suite more fragile. However, it'll allow to expose the effects fo various DAG combine. llvm-svn: 294196
2017-02-07 00:21:41 +08:00
; X64-NEXT: .Lcfi2:
; X64-NEXT: .cfi_def_cfa_offset 32
; X64-NEXT: .Lcfi3:
[DAGCombine] (addcarry 0, 0, X) -> (ext/trunc X) Summary: While this makes some case better and some case worse - so it's unclear if it is a worthy combine just by itself - this is a useful canonicalisation. As per discussion in D32756 . Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32916 llvm-svn: 303441
2017-05-20 02:20:44 +08:00
; X64-NEXT: .cfi_offset %rbx, -32
Commit full codegen for mul-i256.ll . NFC The full codegen is committed for larger multiply, so that won't make the test suite more fragile. However, it'll allow to expose the effects fo various DAG combine. llvm-svn: 294196
2017-02-07 00:21:41 +08:00
; X64-NEXT: .Lcfi4:
; X64-NEXT: .cfi_offset %r14, -24
[DAGCombine] (addcarry 0, 0, X) -> (ext/trunc X) Summary: While this makes some case better and some case worse - so it's unclear if it is a worthy combine just by itself - this is a useful canonicalisation. As per discussion in D32756 . Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32916 llvm-svn: 303441
2017-05-20 02:20:44 +08:00
; X64-NEXT: .Lcfi5:
Commit full codegen for mul-i256.ll . NFC The full codegen is committed for larger multiply, so that won't make the test suite more fragile. However, it'll allow to expose the effects fo various DAG combine. llvm-svn: 294196
2017-02-07 00:21:41 +08:00
; X64-NEXT: .cfi_offset %r15, -16
[DAGCombine] (uaddo X, (addcarry Y, 0, Carry)) -> (addcarry X, Y, Carry) Summary: This is a common pattern that arise when legalizing large integers operations. Only do it when Y + 1 cannot overflow as this would change the carry behavior of uaddo . Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32687 llvm-svn: 301922
2017-05-02 22:15:48 +08:00
; X64-NEXT: movq %rdx, %r9
[DAGCombine] (addcarry 0, 0, X) -> (ext/trunc X) Summary: While this makes some case better and some case worse - so it's unclear if it is a worthy combine just by itself - this is a useful canonicalisation. As per discussion in D32756 . Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32916 llvm-svn: 303441
2017-05-20 02:20:44 +08:00
; X64-NEXT: movq (%rdi), %r11
Commit full codegen for mul-i256.ll . NFC The full codegen is committed for larger multiply, so that won't make the test suite more fragile. However, it'll allow to expose the effects fo various DAG combine. llvm-svn: 294196
2017-02-07 00:21:41 +08:00
; X64-NEXT: movq 8(%rdi), %r8
[DAGCombine] (addcarry 0, 0, X) -> (ext/trunc X) Summary: While this makes some case better and some case worse - so it's unclear if it is a worthy combine just by itself - this is a useful canonicalisation. As per discussion in D32756 . Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32916 llvm-svn: 303441
2017-05-20 02:20:44 +08:00
; X64-NEXT: movq 16(%rdi), %rbx
; X64-NEXT: movq 16(%rsi), %r10
; X64-NEXT: movq (%rsi), %rcx
Commit full codegen for mul-i256.ll . NFC The full codegen is committed for larger multiply, so that won't make the test suite more fragile. However, it'll allow to expose the effects fo various DAG combine. llvm-svn: 294196
2017-02-07 00:21:41 +08:00
; X64-NEXT: movq 8(%rsi), %r15
; X64-NEXT: movq 24(%rdi), %rdi
[DAGCombine] (addcarry 0, 0, X) -> (ext/trunc X) Summary: While this makes some case better and some case worse - so it's unclear if it is a worthy combine just by itself - this is a useful canonicalisation. As per discussion in D32756 . Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32916 llvm-svn: 303441
2017-05-20 02:20:44 +08:00
; X64-NEXT: imulq %rcx, %rdi
; X64-NEXT: movq %rcx, %rax
; X64-NEXT: mulq %rbx
; X64-NEXT: movq %rax, %r14
Commit full codegen for mul-i256.ll . NFC The full codegen is committed for larger multiply, so that won't make the test suite more fragile. However, it'll allow to expose the effects fo various DAG combine. llvm-svn: 294196
2017-02-07 00:21:41 +08:00
; X64-NEXT: addq %rdi, %rdx
[DAGCombine] (addcarry 0, 0, X) -> (ext/trunc X) Summary: While this makes some case better and some case worse - so it's unclear if it is a worthy combine just by itself - this is a useful canonicalisation. As per discussion in D32756 . Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32916 llvm-svn: 303441
2017-05-20 02:20:44 +08:00
; X64-NEXT: imulq %r15, %rbx
; X64-NEXT: addq %rdx, %rbx
; X64-NEXT: movq %r10, %rdi
Commit full codegen for mul-i256.ll . NFC The full codegen is committed for larger multiply, so that won't make the test suite more fragile. However, it'll allow to expose the effects fo various DAG combine. llvm-svn: 294196
2017-02-07 00:21:41 +08:00
; X64-NEXT: imulq %r8, %rdi
[DAGCombine] (addcarry 0, 0, X) -> (ext/trunc X) Summary: While this makes some case better and some case worse - so it's unclear if it is a worthy combine just by itself - this is a useful canonicalisation. As per discussion in D32756 . Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32916 llvm-svn: 303441
2017-05-20 02:20:44 +08:00
; X64-NEXT: movq %r10, %rax
; X64-NEXT: mulq %r11
; X64-NEXT: movq %rax, %r10
Commit full codegen for mul-i256.ll . NFC The full codegen is committed for larger multiply, so that won't make the test suite more fragile. However, it'll allow to expose the effects fo various DAG combine. llvm-svn: 294196
2017-02-07 00:21:41 +08:00
; X64-NEXT: addq %rdi, %rdx
[DAGCombine] (addcarry 0, 0, X) -> (ext/trunc X) Summary: While this makes some case better and some case worse - so it's unclear if it is a worthy combine just by itself - this is a useful canonicalisation. As per discussion in D32756 . Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32916 llvm-svn: 303441
2017-05-20 02:20:44 +08:00
; X64-NEXT: movq 24(%rsi), %rdi
; X64-NEXT: imulq %r11, %rdi
; X64-NEXT: addq %rdx, %rdi
; X64-NEXT: addq %r14, %r10
; X64-NEXT: adcq %rbx, %rdi
; X64-NEXT: movq %r11, %rax
; X64-NEXT: mulq %rcx
Commit full codegen for mul-i256.ll . NFC The full codegen is committed for larger multiply, so that won't make the test suite more fragile. However, it'll allow to expose the effects fo various DAG combine. llvm-svn: 294196
2017-02-07 00:21:41 +08:00
; X64-NEXT: movq %rdx, %rsi
[DAGCombine] (addcarry 0, 0, X) -> (ext/trunc X) Summary: While this makes some case better and some case worse - so it's unclear if it is a worthy combine just by itself - this is a useful canonicalisation. As per discussion in D32756 . Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32916 llvm-svn: 303441
2017-05-20 02:20:44 +08:00
; X64-NEXT: movq %rax, %r14
Commit full codegen for mul-i256.ll . NFC The full codegen is committed for larger multiply, so that won't make the test suite more fragile. However, it'll allow to expose the effects fo various DAG combine. llvm-svn: 294196
2017-02-07 00:21:41 +08:00
; X64-NEXT: movq %r8, %rax
[DAGCombine] (addcarry 0, 0, X) -> (ext/trunc X) Summary: While this makes some case better and some case worse - so it's unclear if it is a worthy combine just by itself - this is a useful canonicalisation. As per discussion in D32756 . Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32916 llvm-svn: 303441
2017-05-20 02:20:44 +08:00
; X64-NEXT: mulq %rcx
Commit full codegen for mul-i256.ll . NFC The full codegen is committed for larger multiply, so that won't make the test suite more fragile. However, it'll allow to expose the effects fo various DAG combine. llvm-svn: 294196
2017-02-07 00:21:41 +08:00
; X64-NEXT: movq %rdx, %rcx
[DAGCombine] (addcarry 0, 0, X) -> (ext/trunc X) Summary: While this makes some case better and some case worse - so it's unclear if it is a worthy combine just by itself - this is a useful canonicalisation. As per discussion in D32756 . Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32916 llvm-svn: 303441
2017-05-20 02:20:44 +08:00
; X64-NEXT: movq %rax, %rbx
; X64-NEXT: addq %rsi, %rbx
Commit full codegen for mul-i256.ll . NFC The full codegen is committed for larger multiply, so that won't make the test suite more fragile. However, it'll allow to expose the effects fo various DAG combine. llvm-svn: 294196
2017-02-07 00:21:41 +08:00
; X64-NEXT: adcq $0, %rcx
[DAGCombine] (addcarry 0, 0, X) -> (ext/trunc X) Summary: While this makes some case better and some case worse - so it's unclear if it is a worthy combine just by itself - this is a useful canonicalisation. As per discussion in D32756 . Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32916 llvm-svn: 303441
2017-05-20 02:20:44 +08:00
; X64-NEXT: movq %r11, %rax
Commit full codegen for mul-i256.ll . NFC The full codegen is committed for larger multiply, so that won't make the test suite more fragile. However, it'll allow to expose the effects fo various DAG combine. llvm-svn: 294196
2017-02-07 00:21:41 +08:00
; X64-NEXT: mulq %r15
; X64-NEXT: movq %rdx, %rsi
[DAGCombine] (addcarry 0, 0, X) -> (ext/trunc X) Summary: While this makes some case better and some case worse - so it's unclear if it is a worthy combine just by itself - this is a useful canonicalisation. As per discussion in D32756 . Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32916 llvm-svn: 303441
2017-05-20 02:20:44 +08:00
; X64-NEXT: movq %rax, %r11
; X64-NEXT: addq %rbx, %r11
[DAGCombine] (uaddo X, (addcarry Y, 0, Carry)) -> (addcarry X, Y, Carry) Summary: This is a common pattern that arise when legalizing large integers operations. Only do it when Y + 1 cannot overflow as this would change the carry behavior of uaddo . Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32687 llvm-svn: 301922
2017-05-02 22:15:48 +08:00
; X64-NEXT: adcq %rcx, %rsi
[DAGCombine] (addcarry 0, 0, X) -> (ext/trunc X) Summary: While this makes some case better and some case worse - so it's unclear if it is a worthy combine just by itself - this is a useful canonicalisation. As per discussion in D32756 . Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32916 llvm-svn: 303441
2017-05-20 02:20:44 +08:00
; X64-NEXT: setb %al
; X64-NEXT: movzbl %al, %ecx
Commit full codegen for mul-i256.ll . NFC The full codegen is committed for larger multiply, so that won't make the test suite more fragile. However, it'll allow to expose the effects fo various DAG combine. llvm-svn: 294196
2017-02-07 00:21:41 +08:00
; X64-NEXT: movq %r8, %rax
; X64-NEXT: mulq %r15
; X64-NEXT: addq %rsi, %rax
; X64-NEXT: adcq %rcx, %rdx
[DAGCombine] (addcarry 0, 0, X) -> (ext/trunc X) Summary: While this makes some case better and some case worse - so it's unclear if it is a worthy combine just by itself - this is a useful canonicalisation. As per discussion in D32756 . Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32916 llvm-svn: 303441
2017-05-20 02:20:44 +08:00
; X64-NEXT: addq %r10, %rax
; X64-NEXT: adcq %rdi, %rdx
; X64-NEXT: movq %r14, (%r9)
; X64-NEXT: movq %r11, 8(%r9)
[DAGCombine] (uaddo X, (addcarry Y, 0, Carry)) -> (addcarry X, Y, Carry) Summary: This is a common pattern that arise when legalizing large integers operations. Only do it when Y + 1 cannot overflow as this would change the carry behavior of uaddo . Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32687 llvm-svn: 301922
2017-05-02 22:15:48 +08:00
; X64-NEXT: movq %rax, 16(%r9)
; X64-NEXT: movq %rdx, 24(%r9)
Commit full codegen for mul-i256.ll . NFC The full codegen is committed for larger multiply, so that won't make the test suite more fragile. However, it'll allow to expose the effects fo various DAG combine. llvm-svn: 294196
2017-02-07 00:21:41 +08:00
; X64-NEXT: popq %rbx
; X64-NEXT: popq %r14
; X64-NEXT: popq %r15
; X64-NEXT: retq
[SDAG] Add a fallback multiplication expansion LegalizeIntegerTypes does not have a way to expand multiplications for large integer types (i.e. larger than twice the native bit width). There's no standard runtime call to use in that case, and so we'd just assert. Unfortunately, as it turns out, it is possible to hit this case from standard-ish C code in rare cases. A particular case a user ran into yesterday involved an __int128 induction variable and a loop with a quadratic (not linear) recurrence which triggered some backend logic using SCEVExpander. In this case, the BinomialCoefficient code in SCEV generates some i129 variables, which get widened to i256. At a high level, this is not actually good (i.e. the underlying optimization, PPCLoopPreIncPrep, should not be transforming the loop in question for performance reasons), but regardless, the backend shouldn't crash because of cost-modeling issues in the optimizer. This is a straightforward implementation of the multiplication expansion, based on the algorithm in Hacker's Delight. I validated it against the code for the mul256b function from http://locklessinc.com/articles/256bit_arithmetic/ using random inputs. There should be no functional change for previously-working code (the new expansion code only replaces an assert). Fixes PR19797. llvm-svn: 270720
2016-05-26 00:50:22 +08:00
entry:
%av = load i256, i256* %a
%bv = load i256, i256* %b
%r = mul i256 %av, %bv
store i256 %r, i256* %out
ret void
}
attributes #0 = { norecurse nounwind uwtable "target-cpu"="x86-64" "target-features"="+fxsr,+mmx,+sse,+sse2,+x87" }