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

444 lines
17 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"
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:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; X32: # %bb.0: # %entry
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: pushl %ebp
; X32-NEXT: .cfi_def_cfa_offset 8
; X32-NEXT: pushl %ebx
[X86] Do not generate __multi3 for mul i128 on X86 Summary: __multi3 is not available on x86 (32-bit). Setting lib call name for MULI_128 to nullptr forces DAGTypeLegalizer::ExpandIntRes_MUL to generate instructions for 128-bit multiply instead of a call to an undefined function. This fixes PR20871 though it may be worth looking at why licm and indvars combine to generate 65-bit multiplies in that test. Patch by Riyaz V Puthiyapurayil Reviewers: craig.topper, schweitz Reviewed By: craig.topper, schweitz Subscribers: RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D38668 llvm-svn: 316254
2017-10-21 10:26:00 +08:00
; X32-NEXT: .cfi_def_cfa_offset 12
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: pushl %edi
[X86] Do not generate __multi3 for mul i128 on X86 Summary: __multi3 is not available on x86 (32-bit). Setting lib call name for MULI_128 to nullptr forces DAGTypeLegalizer::ExpandIntRes_MUL to generate instructions for 128-bit multiply instead of a call to an undefined function. This fixes PR20871 though it may be worth looking at why licm and indvars combine to generate 65-bit multiplies in that test. Patch by Riyaz V Puthiyapurayil Reviewers: craig.topper, schweitz Reviewed By: craig.topper, schweitz Subscribers: RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D38668 llvm-svn: 316254
2017-10-21 10:26:00 +08:00
; X32-NEXT: .cfi_def_cfa_offset 16
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: pushl %esi
[X86] Do not generate __multi3 for mul i128 on X86 Summary: __multi3 is not available on x86 (32-bit). Setting lib call name for MULI_128 to nullptr forces DAGTypeLegalizer::ExpandIntRes_MUL to generate instructions for 128-bit multiply instead of a call to an undefined function. This fixes PR20871 though it may be worth looking at why licm and indvars combine to generate 65-bit multiplies in that test. Patch by Riyaz V Puthiyapurayil Reviewers: craig.topper, schweitz Reviewed By: craig.topper, schweitz Subscribers: RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D38668 llvm-svn: 316254
2017-10-21 10:26:00 +08:00
; X32-NEXT: .cfi_def_cfa_offset 20
; X32-NEXT: subl $88, %esp
; X32-NEXT: .cfi_def_cfa_offset 108
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: .cfi_offset %esi, -20
; X32-NEXT: .cfi_offset %edi, -16
; X32-NEXT: .cfi_offset %ebx, -12
[X86] Do not generate __multi3 for mul i128 on X86 Summary: __multi3 is not available on x86 (32-bit). Setting lib call name for MULI_128 to nullptr forces DAGTypeLegalizer::ExpandIntRes_MUL to generate instructions for 128-bit multiply instead of a call to an undefined function. This fixes PR20871 though it may be worth looking at why licm and indvars combine to generate 65-bit multiplies in that test. Patch by Riyaz V Puthiyapurayil Reviewers: craig.topper, schweitz Reviewed By: craig.topper, schweitz Subscribers: RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D38668 llvm-svn: 316254
2017-10-21 10:26:00 +08:00
; X32-NEXT: .cfi_offset %ebp, -8
; X32-NEXT: movl {{[0-9]+}}(%esp), %eax
; X32-NEXT: movl {{[0-9]+}}(%esp), %ecx
; X32-NEXT: movl 12(%ecx), %ebp
; X32-NEXT: movl 8(%ecx), %edi
; X32-NEXT: movl %edi, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl (%eax), %ebx
; X32-NEXT: movl %ebx, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl %edi, %eax
; X32-NEXT: mull %ebx
; X32-NEXT: movl %edx, %ecx
; X32-NEXT: movl %eax, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl %ebp, %eax
; X32-NEXT: movl %ebp, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: mull %ebx
; X32-NEXT: movl %edx, %esi
; X32-NEXT: movl %eax, %ebx
; X32-NEXT: addl %ecx, %ebx
; X32-NEXT: adcl $0, %esi
; X32-NEXT: movl {{[0-9]+}}(%esp), %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: movl 4(%eax), %ecx
[X86] Do not generate __multi3 for mul i128 on X86 Summary: __multi3 is not available on x86 (32-bit). Setting lib call name for MULI_128 to nullptr forces DAGTypeLegalizer::ExpandIntRes_MUL to generate instructions for 128-bit multiply instead of a call to an undefined function. This fixes PR20871 though it may be worth looking at why licm and indvars combine to generate 65-bit multiplies in that test. Patch by Riyaz V Puthiyapurayil Reviewers: craig.topper, schweitz Reviewed By: craig.topper, schweitz Subscribers: RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D38668 llvm-svn: 316254
2017-10-21 10:26:00 +08:00
; X32-NEXT: movl %edi, %eax
; X32-NEXT: mull %ecx
; X32-NEXT: movl %ecx, %edi
Re-enable "[MachineCopyPropagation] Extend pass to do COPY source forwarding" Re-enable commit r323991 now that r325931 has been committed to make MachineOperand::isRenamable() check more conservative w.r.t. code changes and opt-in on a per-target basis. llvm-svn: 326208
2018-02-28 00:59:10 +08:00
; X32-NEXT: movl %ecx, {{[0-9]+}}(%esp) # 4-byte Spill
[X86] Do not generate __multi3 for mul i128 on X86 Summary: __multi3 is not available on x86 (32-bit). Setting lib call name for MULI_128 to nullptr forces DAGTypeLegalizer::ExpandIntRes_MUL to generate instructions for 128-bit multiply instead of a call to an undefined function. This fixes PR20871 though it may be worth looking at why licm and indvars combine to generate 65-bit multiplies in that test. Patch by Riyaz V Puthiyapurayil Reviewers: craig.topper, schweitz Reviewed By: craig.topper, schweitz Subscribers: RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D38668 llvm-svn: 316254
2017-10-21 10:26:00 +08:00
; X32-NEXT: movl %edx, %ecx
; X32-NEXT: addl %ebx, %eax
; X32-NEXT: movl %eax, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: adcl %esi, %ecx
; X32-NEXT: setb {{[0-9]+}}(%esp) # 1-byte Folded Spill
; X32-NEXT: movl %ebp, %eax
; X32-NEXT: mull %edi
; X32-NEXT: movl %edx, %ebx
; X32-NEXT: movl %eax, %edi
; X32-NEXT: addl %ecx, %edi
; X32-NEXT: movzbl {{[0-9]+}}(%esp), %eax # 1-byte Folded Reload
; X32-NEXT: adcl %eax, %ebx
; X32-NEXT: xorl %edx, %edx
; X32-NEXT: movl {{[0-9]+}}(%esp), %ecx # 4-byte Reload
; X32-NEXT: movl %ecx, %eax
; X32-NEXT: mull %edx
; X32-NEXT: movl %edx, %ebp
Re-enable "[MachineCopyPropagation] Extend pass to do COPY source forwarding" Re-enable commit r323991 now that r325931 has been committed to make MachineOperand::isRenamable() check more conservative w.r.t. code changes and opt-in on a per-target basis. llvm-svn: 326208
2018-02-28 00:59:10 +08:00
; X32-NEXT: movl %edx, {{[0-9]+}}(%esp) # 4-byte Spill
[X86] Do not generate __multi3 for mul i128 on X86 Summary: __multi3 is not available on x86 (32-bit). Setting lib call name for MULI_128 to nullptr forces DAGTypeLegalizer::ExpandIntRes_MUL to generate instructions for 128-bit multiply instead of a call to an undefined function. This fixes PR20871 though it may be worth looking at why licm and indvars combine to generate 65-bit multiplies in that test. Patch by Riyaz V Puthiyapurayil Reviewers: craig.topper, schweitz Reviewed By: craig.topper, schweitz Subscribers: RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D38668 llvm-svn: 316254
2017-10-21 10:26:00 +08:00
; X32-NEXT: movl %eax, %esi
Re-enable "[MachineCopyPropagation] Extend pass to do COPY source forwarding" Re-enable commit r323991 now that r325931 has been committed to make MachineOperand::isRenamable() check more conservative w.r.t. code changes and opt-in on a per-target basis. llvm-svn: 326208
2018-02-28 00:59:10 +08:00
; X32-NEXT: movl %eax, (%esp) # 4-byte Spill
[X86] Do not generate __multi3 for mul i128 on X86 Summary: __multi3 is not available on x86 (32-bit). Setting lib call name for MULI_128 to nullptr forces DAGTypeLegalizer::ExpandIntRes_MUL to generate instructions for 128-bit multiply instead of a call to an undefined function. This fixes PR20871 though it may be worth looking at why licm and indvars combine to generate 65-bit multiplies in that test. Patch by Riyaz V Puthiyapurayil Reviewers: craig.topper, schweitz Reviewed By: craig.topper, schweitz Subscribers: RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D38668 llvm-svn: 316254
2017-10-21 10:26:00 +08:00
; X32-NEXT: movl {{[0-9]+}}(%esp), %eax # 4-byte Reload
; X32-NEXT: xorl %edx, %edx
; X32-NEXT: mull %edx
; X32-NEXT: movl %edx, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl %eax, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: addl %esi, %eax
; X32-NEXT: adcl %ebp, %edx
; X32-NEXT: addl %edi, %eax
; X32-NEXT: movl %eax, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: adcl %ebx, %edx
; X32-NEXT: movl %edx, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl {{[0-9]+}}(%esp), %esi
; X32-NEXT: movl (%esi), %ebp
; X32-NEXT: movl %ebp, %eax
; X32-NEXT: movl %ebp, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: mull %ecx
; X32-NEXT: movl %ecx, %edi
; X32-NEXT: movl %eax, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl %edx, %ecx
; X32-NEXT: movl 4(%esi), %esi
; X32-NEXT: movl %esi, %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: movl %esi, {{[0-9]+}}(%esp) # 4-byte Spill
[X86] Do not generate __multi3 for mul i128 on X86 Summary: __multi3 is not available on x86 (32-bit). Setting lib call name for MULI_128 to nullptr forces DAGTypeLegalizer::ExpandIntRes_MUL to generate instructions for 128-bit multiply instead of a call to an undefined function. This fixes PR20871 though it may be worth looking at why licm and indvars combine to generate 65-bit multiplies in that test. Patch by Riyaz V Puthiyapurayil Reviewers: craig.topper, schweitz Reviewed By: craig.topper, schweitz Subscribers: RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D38668 llvm-svn: 316254
2017-10-21 10:26:00 +08:00
; X32-NEXT: mull %edi
; X32-NEXT: movl %edx, %edi
; X32-NEXT: movl %eax, %ebx
; X32-NEXT: addl %ecx, %ebx
; X32-NEXT: adcl $0, %edi
; X32-NEXT: movl %ebp, %eax
; X32-NEXT: movl {{[0-9]+}}(%esp), %ebp # 4-byte Reload
; X32-NEXT: mull %ebp
; X32-NEXT: movl %edx, %ecx
; X32-NEXT: addl %ebx, %eax
; X32-NEXT: movl %eax, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: adcl %edi, %ecx
; X32-NEXT: setb %bl
; X32-NEXT: movl %esi, %eax
; X32-NEXT: mull %ebp
; X32-NEXT: movl %edx, %edi
; X32-NEXT: movl %eax, %ebp
; X32-NEXT: addl %ecx, %ebp
; X32-NEXT: movzbl %bl, %eax
; X32-NEXT: adcl %eax, %edi
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: movl {{[0-9]+}}(%esp), %esi # 4-byte Reload
[X86] Do not generate __multi3 for mul i128 on X86 Summary: __multi3 is not available on x86 (32-bit). Setting lib call name for MULI_128 to nullptr forces DAGTypeLegalizer::ExpandIntRes_MUL to generate instructions for 128-bit multiply instead of a call to an undefined function. This fixes PR20871 though it may be worth looking at why licm and indvars combine to generate 65-bit multiplies in that test. Patch by Riyaz V Puthiyapurayil Reviewers: craig.topper, schweitz Reviewed By: craig.topper, schweitz Subscribers: RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D38668 llvm-svn: 316254
2017-10-21 10:26:00 +08:00
; X32-NEXT: movl %esi, %eax
; X32-NEXT: xorl %edx, %edx
; X32-NEXT: mull %edx
; X32-NEXT: movl %edx, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl %eax, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl (%esp), %ecx # 4-byte Reload
; X32-NEXT: addl %eax, %ecx
; X32-NEXT: movl {{[0-9]+}}(%esp), %eax # 4-byte Reload
; X32-NEXT: adcl %edx, %eax
; X32-NEXT: addl %ebp, %ecx
; X32-NEXT: adcl %edi, %eax
; X32-NEXT: addl {{[0-9]+}}(%esp), %ecx # 4-byte Folded Reload
; X32-NEXT: movl %ecx, (%esp) # 4-byte Spill
; X32-NEXT: adcl {{[0-9]+}}(%esp), %eax # 4-byte Folded Reload
; X32-NEXT: movl %eax, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: adcl $0, {{[0-9]+}}(%esp) # 4-byte Folded Spill
; X32-NEXT: adcl $0, {{[0-9]+}}(%esp) # 4-byte Folded 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: movl {{[0-9]+}}(%esp), %eax
[X86] Do not generate __multi3 for mul i128 on X86 Summary: __multi3 is not available on x86 (32-bit). Setting lib call name for MULI_128 to nullptr forces DAGTypeLegalizer::ExpandIntRes_MUL to generate instructions for 128-bit multiply instead of a call to an undefined function. This fixes PR20871 though it may be worth looking at why licm and indvars combine to generate 65-bit multiplies in that test. Patch by Riyaz V Puthiyapurayil Reviewers: craig.topper, schweitz Reviewed By: craig.topper, schweitz Subscribers: RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D38668 llvm-svn: 316254
2017-10-21 10:26:00 +08:00
; X32-NEXT: movl %eax, %ecx
Re-enable "[MachineCopyPropagation] Extend pass to do COPY source forwarding" Re-enable commit r323991 now that r325931 has been committed to make MachineOperand::isRenamable() check more conservative w.r.t. code changes and opt-in on a per-target basis. llvm-svn: 326208
2018-02-28 00:59:10 +08:00
; X32-NEXT: movl 8(%eax), %ebx
[X86] Do not generate __multi3 for mul i128 on X86 Summary: __multi3 is not available on x86 (32-bit). Setting lib call name for MULI_128 to nullptr forces DAGTypeLegalizer::ExpandIntRes_MUL to generate instructions for 128-bit multiply instead of a call to an undefined function. This fixes PR20871 though it may be worth looking at why licm and indvars combine to generate 65-bit multiplies in that test. Patch by Riyaz V Puthiyapurayil Reviewers: craig.topper, schweitz Reviewed By: craig.topper, schweitz Subscribers: RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D38668 llvm-svn: 316254
2017-10-21 10:26:00 +08:00
; X32-NEXT: movl %esi, %eax
; X32-NEXT: movl %esi, %edi
; X32-NEXT: mull %ebx
; X32-NEXT: movl %edx, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl %eax, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl {{[0-9]+}}(%esp), %eax # 4-byte Reload
; X32-NEXT: mull %ebx
; X32-NEXT: movl %edx, %ebp
; X32-NEXT: movl %eax, %esi
; X32-NEXT: addl {{[0-9]+}}(%esp), %esi # 4-byte Folded Reload
; X32-NEXT: adcl $0, %ebp
; X32-NEXT: movl 12(%ecx), %ecx
; X32-NEXT: movl %edi, %eax
; X32-NEXT: mull %ecx
; X32-NEXT: movl %ecx, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl %edx, %edi
; X32-NEXT: addl %esi, %eax
; X32-NEXT: movl %eax, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: adcl %ebp, %edi
; X32-NEXT: setb {{[0-9]+}}(%esp) # 1-byte Folded Spill
; X32-NEXT: movl {{[0-9]+}}(%esp), %eax # 4-byte Reload
; X32-NEXT: mull %ecx
; X32-NEXT: movl %edx, %esi
; X32-NEXT: movl %eax, %ebp
; X32-NEXT: addl %edi, %ebp
; X32-NEXT: movzbl {{[0-9]+}}(%esp), %eax # 1-byte Folded Reload
; X32-NEXT: adcl %eax, %esi
; X32-NEXT: movl %ebx, %edi
Re-enable "[MachineCopyPropagation] Extend pass to do COPY source forwarding" Re-enable commit r323991 now that r325931 has been committed to make MachineOperand::isRenamable() check more conservative w.r.t. code changes and opt-in on a per-target basis. llvm-svn: 326208
2018-02-28 00:59:10 +08:00
; X32-NEXT: movl %ebx, %eax
[X86] Do not generate __multi3 for mul i128 on X86 Summary: __multi3 is not available on x86 (32-bit). Setting lib call name for MULI_128 to nullptr forces DAGTypeLegalizer::ExpandIntRes_MUL to generate instructions for 128-bit multiply instead of a call to an undefined function. This fixes PR20871 though it may be worth looking at why licm and indvars combine to generate 65-bit multiplies in that test. Patch by Riyaz V Puthiyapurayil Reviewers: craig.topper, schweitz Reviewed By: craig.topper, schweitz Subscribers: RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D38668 llvm-svn: 316254
2017-10-21 10:26:00 +08:00
; X32-NEXT: xorl %ecx, %ecx
; X32-NEXT: mull %ecx
; X32-NEXT: movl %edx, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl %eax, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl {{[0-9]+}}(%esp), %ebx # 4-byte Reload
; X32-NEXT: addl %eax, %ebx
; X32-NEXT: movl {{[0-9]+}}(%esp), %eax # 4-byte Reload
; X32-NEXT: adcl %edx, %eax
; X32-NEXT: addl %ebp, %ebx
; X32-NEXT: adcl %esi, %eax
; X32-NEXT: movl (%esp), %ecx # 4-byte Reload
; X32-NEXT: addl %ecx, {{[0-9]+}}(%esp) # 4-byte Folded Spill
; X32-NEXT: movl {{[0-9]+}}(%esp), %ecx # 4-byte Reload
; X32-NEXT: adcl %ecx, {{[0-9]+}}(%esp) # 4-byte Folded Spill
; X32-NEXT: adcl $0, %ebx
; X32-NEXT: adcl $0, %eax
; X32-NEXT: addl {{[0-9]+}}(%esp), %ebx # 4-byte Folded Reload
; X32-NEXT: movl %ebx, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: adcl {{[0-9]+}}(%esp), %eax # 4-byte Folded Reload
; X32-NEXT: movl %eax, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: setb (%esp) # 1-byte Folded Spill
; X32-NEXT: movl {{[0-9]+}}(%esp), %esi # 4-byte Reload
; X32-NEXT: movl %esi, %eax
; X32-NEXT: movl %edi, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: mull %edi
; X32-NEXT: movl %edx, %ebx
; X32-NEXT: movl %eax, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl {{[0-9]+}}(%esp), %ecx # 4-byte Reload
; X32-NEXT: movl %ecx, %eax
; X32-NEXT: mull %edi
; X32-NEXT: movl %edx, %edi
; X32-NEXT: movl %eax, %ebp
; X32-NEXT: addl %ebx, %ebp
; X32-NEXT: adcl $0, %edi
; X32-NEXT: movl %esi, %eax
; X32-NEXT: movl {{[0-9]+}}(%esp), %ebx # 4-byte Reload
; X32-NEXT: mull %ebx
; X32-NEXT: movl %edx, %esi
; X32-NEXT: addl %ebp, %eax
; X32-NEXT: movl %eax, %ebp
; X32-NEXT: adcl %edi, %esi
; X32-NEXT: setb {{[0-9]+}}(%esp) # 1-byte Folded Spill
; X32-NEXT: movl %ecx, %eax
; X32-NEXT: mull %ebx
; X32-NEXT: addl %esi, %eax
; X32-NEXT: movzbl {{[0-9]+}}(%esp), %esi # 1-byte Folded Reload
; X32-NEXT: adcl %esi, %edx
; X32-NEXT: movl {{[0-9]+}}(%esp), %esi # 4-byte Reload
; X32-NEXT: addl {{[0-9]+}}(%esp), %esi # 4-byte Folded Reload
; X32-NEXT: movl {{[0-9]+}}(%esp), %ecx # 4-byte Reload
; X32-NEXT: adcl {{[0-9]+}}(%esp), %ecx # 4-byte Folded Reload
; X32-NEXT: addl %eax, %esi
; X32-NEXT: adcl %edx, %ecx
; X32-NEXT: movl {{[0-9]+}}(%esp), %eax # 4-byte Reload
; X32-NEXT: addl %eax, {{[0-9]+}}(%esp) # 4-byte Folded Spill
; X32-NEXT: adcl {{[0-9]+}}(%esp), %ebp # 4-byte Folded Reload
; X32-NEXT: movl %ebp, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movzbl (%esp), %eax # 1-byte Folded Reload
; X32-NEXT: adcl %eax, %esi
; X32-NEXT: movl %esi, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: adcl $0, %ecx
; X32-NEXT: movl %ecx, {{[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: movl {{[0-9]+}}(%esp), %ecx
[X86] Do not generate __multi3 for mul i128 on X86 Summary: __multi3 is not available on x86 (32-bit). Setting lib call name for MULI_128 to nullptr forces DAGTypeLegalizer::ExpandIntRes_MUL to generate instructions for 128-bit multiply instead of a call to an undefined function. This fixes PR20871 though it may be worth looking at why licm and indvars combine to generate 65-bit multiplies in that test. Patch by Riyaz V Puthiyapurayil Reviewers: craig.topper, schweitz Reviewed By: craig.topper, schweitz Subscribers: RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D38668 llvm-svn: 316254
2017-10-21 10:26:00 +08:00
; X32-NEXT: movl 16(%ecx), %esi
; X32-NEXT: imull %esi, %ebx
; X32-NEXT: movl %esi, %eax
; X32-NEXT: movl {{[0-9]+}}(%esp), %edi # 4-byte Reload
; X32-NEXT: mull %edi
; X32-NEXT: movl %eax, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: addl %ebx, %edx
; X32-NEXT: movl 20(%ecx), %eax
; X32-NEXT: movl %eax, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: imull %eax, %edi
; X32-NEXT: addl %edx, %edi
; X32-NEXT: movl %edi, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl 24(%ecx), %eax
; X32-NEXT: movl %ecx, %ebp
; X32-NEXT: movl %eax, %edi
; X32-NEXT: movl {{[0-9]+}}(%esp), %ecx # 4-byte Reload
; X32-NEXT: imull %ecx, %edi
; X32-NEXT: movl {{[0-9]+}}(%esp), %ebx # 4-byte Reload
; X32-NEXT: mull %ebx
; X32-NEXT: movl %eax, (%esp) # 4-byte Spill
; X32-NEXT: addl %edi, %edx
; X32-NEXT: movl 28(%ebp), %ebp
; X32-NEXT: imull %ebx, %ebp
; X32-NEXT: addl %edx, %ebp
; X32-NEXT: movl {{[0-9]+}}(%esp), %edx # 4-byte Reload
; X32-NEXT: addl %edx, (%esp) # 4-byte Folded Spill
; X32-NEXT: adcl {{[0-9]+}}(%esp), %ebp # 4-byte Folded Reload
; X32-NEXT: movl %ebx, %eax
; X32-NEXT: mull %esi
; X32-NEXT: movl %edx, %ebx
; X32-NEXT: movl %eax, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl %ecx, %eax
; X32-NEXT: mull %esi
; X32-NEXT: movl %edx, %ecx
; X32-NEXT: movl %eax, %edi
; X32-NEXT: addl %ebx, %edi
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, %ecx
[X86] Do not generate __multi3 for mul i128 on X86 Summary: __multi3 is not available on x86 (32-bit). Setting lib call name for MULI_128 to nullptr forces DAGTypeLegalizer::ExpandIntRes_MUL to generate instructions for 128-bit multiply instead of a call to an undefined function. This fixes PR20871 though it may be worth looking at why licm and indvars combine to generate 65-bit multiplies in that test. Patch by Riyaz V Puthiyapurayil Reviewers: craig.topper, schweitz Reviewed By: craig.topper, schweitz Subscribers: RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D38668 llvm-svn: 316254
2017-10-21 10:26:00 +08:00
; X32-NEXT: movl {{[0-9]+}}(%esp), %eax # 4-byte Reload
; X32-NEXT: movl {{[0-9]+}}(%esp), %ebx # 4-byte Reload
; X32-NEXT: mull %ebx
; X32-NEXT: movl %edx, %esi
; X32-NEXT: addl %edi, %eax
; X32-NEXT: movl %eax, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: adcl %ecx, %esi
; X32-NEXT: setb %cl
; X32-NEXT: movl {{[0-9]+}}(%esp), %eax # 4-byte Reload
; X32-NEXT: mull %ebx
; X32-NEXT: addl %esi, %eax
; X32-NEXT: movzbl %cl, %ecx
; X32-NEXT: adcl %ecx, %edx
; X32-NEXT: addl (%esp), %eax # 4-byte Folded Reload
; X32-NEXT: movl %eax, (%esp) # 4-byte Spill
; X32-NEXT: adcl %ebp, %edx
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: movl %edx, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl {{[0-9]+}}(%esp), %ebx
[X86] Do not generate __multi3 for mul i128 on X86 Summary: __multi3 is not available on x86 (32-bit). Setting lib call name for MULI_128 to nullptr forces DAGTypeLegalizer::ExpandIntRes_MUL to generate instructions for 128-bit multiply instead of a call to an undefined function. This fixes PR20871 though it may be worth looking at why licm and indvars combine to generate 65-bit multiplies in that test. Patch by Riyaz V Puthiyapurayil Reviewers: craig.topper, schweitz Reviewed By: craig.topper, schweitz Subscribers: RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D38668 llvm-svn: 316254
2017-10-21 10:26:00 +08:00
; X32-NEXT: movl 28(%ebx), %ecx
; X32-NEXT: movl {{[0-9]+}}(%esp), %esi # 4-byte Reload
; X32-NEXT: imull %esi, %ecx
; X32-NEXT: movl 24(%ebx), %edi
; X32-NEXT: movl %esi, %eax
; X32-NEXT: mull %edi
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: movl %eax, {{[0-9]+}}(%esp) # 4-byte Spill
[X86] Do not generate __multi3 for mul i128 on X86 Summary: __multi3 is not available on x86 (32-bit). Setting lib call name for MULI_128 to nullptr forces DAGTypeLegalizer::ExpandIntRes_MUL to generate instructions for 128-bit multiply instead of a call to an undefined function. This fixes PR20871 though it may be worth looking at why licm and indvars combine to generate 65-bit multiplies in that test. Patch by Riyaz V Puthiyapurayil Reviewers: craig.topper, schweitz Reviewed By: craig.topper, schweitz Subscribers: RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D38668 llvm-svn: 316254
2017-10-21 10:26:00 +08:00
; X32-NEXT: addl %ecx, %edx
; X32-NEXT: imull {{[0-9]+}}(%esp), %edi # 4-byte Folded Reload
; X32-NEXT: addl %edx, %edi
; X32-NEXT: movl 16(%ebx), %ebp
; X32-NEXT: movl 20(%ebx), %ebx
; X32-NEXT: movl {{[0-9]+}}(%esp), %eax # 4-byte Reload
; X32-NEXT: movl %eax, %ecx
; X32-NEXT: imull %ebx, %ecx
; X32-NEXT: movl %ebx, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: mull %ebp
; X32-NEXT: addl %ecx, %edx
; X32-NEXT: movl {{[0-9]+}}(%esp), %ecx # 4-byte Reload
; X32-NEXT: imull %ebp, %ecx
; X32-NEXT: addl %edx, %ecx
; X32-NEXT: addl {{[0-9]+}}(%esp), %eax # 4-byte Folded Reload
[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 %eax, {{[0-9]+}}(%esp) # 4-byte Spill
[X86] Do not generate __multi3 for mul i128 on X86 Summary: __multi3 is not available on x86 (32-bit). Setting lib call name for MULI_128 to nullptr forces DAGTypeLegalizer::ExpandIntRes_MUL to generate instructions for 128-bit multiply instead of a call to an undefined function. This fixes PR20871 though it may be worth looking at why licm and indvars combine to generate 65-bit multiplies in that test. Patch by Riyaz V Puthiyapurayil Reviewers: craig.topper, schweitz Reviewed By: craig.topper, schweitz Subscribers: RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D38668 llvm-svn: 316254
2017-10-21 10:26:00 +08:00
; X32-NEXT: adcl %edi, %ecx
; X32-NEXT: movl %ecx, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl %ebp, %eax
; X32-NEXT: mull %esi
; X32-NEXT: movl %edx, %edi
; X32-NEXT: movl %eax, {{[0-9]+}}(%esp) # 4-byte Spill
; X32-NEXT: movl %ebx, %eax
; X32-NEXT: mull %esi
; X32-NEXT: movl %edx, %ecx
; X32-NEXT: movl %eax, %ebx
; X32-NEXT: addl %edi, %ebx
; X32-NEXT: adcl $0, %ecx
; X32-NEXT: movl %ebp, %eax
; X32-NEXT: movl {{[0-9]+}}(%esp), %ebp # 4-byte Reload
; X32-NEXT: mull %ebp
; X32-NEXT: movl %edx, %edi
; X32-NEXT: movl %eax, %esi
; X32-NEXT: addl %ebx, %esi
; X32-NEXT: adcl %ecx, %edi
; X32-NEXT: setb %cl
; X32-NEXT: movl {{[0-9]+}}(%esp), %eax # 4-byte Reload
; X32-NEXT: mull %ebp
; X32-NEXT: addl %edi, %eax
; X32-NEXT: movzbl %cl, %ecx
; X32-NEXT: adcl %ecx, %edx
; X32-NEXT: addl {{[0-9]+}}(%esp), %eax # 4-byte Folded Reload
; X32-NEXT: adcl {{[0-9]+}}(%esp), %edx # 4-byte Folded Reload
; X32-NEXT: movl {{[0-9]+}}(%esp), %ecx # 4-byte Reload
; X32-NEXT: addl {{[0-9]+}}(%esp), %ecx # 4-byte Folded Reload
; X32-NEXT: adcl {{[0-9]+}}(%esp), %esi # 4-byte Folded Reload
; X32-NEXT: adcl (%esp), %eax # 4-byte Folded Reload
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), %edx # 4-byte Folded Reload
[X86] Do not generate __multi3 for mul i128 on X86 Summary: __multi3 is not available on x86 (32-bit). Setting lib call name for MULI_128 to nullptr forces DAGTypeLegalizer::ExpandIntRes_MUL to generate instructions for 128-bit multiply instead of a call to an undefined function. This fixes PR20871 though it may be worth looking at why licm and indvars combine to generate 65-bit multiplies in that test. Patch by Riyaz V Puthiyapurayil Reviewers: craig.topper, schweitz Reviewed By: craig.topper, schweitz Subscribers: RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D38668 llvm-svn: 316254
2017-10-21 10:26:00 +08:00
; X32-NEXT: addl {{[0-9]+}}(%esp), %ecx # 4-byte Folded Reload
; X32-NEXT: movl %ecx, %ebx
; X32-NEXT: adcl {{[0-9]+}}(%esp), %esi # 4-byte Folded Reload
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 # 4-byte Folded Reload
[X86] Do not generate __multi3 for mul i128 on X86 Summary: __multi3 is not available on x86 (32-bit). Setting lib call name for MULI_128 to nullptr forces DAGTypeLegalizer::ExpandIntRes_MUL to generate instructions for 128-bit multiply instead of a call to an undefined function. This fixes PR20871 though it may be worth looking at why licm and indvars combine to generate 65-bit multiplies in that test. Patch by Riyaz V Puthiyapurayil Reviewers: craig.topper, schweitz Reviewed By: craig.topper, schweitz Subscribers: RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D38668 llvm-svn: 316254
2017-10-21 10:26:00 +08:00
; X32-NEXT: adcl {{[0-9]+}}(%esp), %edx # 4-byte Folded Reload
; X32-NEXT: movl {{[0-9]+}}(%esp), %ecx
; X32-NEXT: movl {{[0-9]+}}(%esp), %edi # 4-byte Reload
; X32-NEXT: movl %edi, (%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
; X32-NEXT: movl {{[0-9]+}}(%esp), %edi # 4-byte Reload
[X86] Do not generate __multi3 for mul i128 on X86 Summary: __multi3 is not available on x86 (32-bit). Setting lib call name for MULI_128 to nullptr forces DAGTypeLegalizer::ExpandIntRes_MUL to generate instructions for 128-bit multiply instead of a call to an undefined function. This fixes PR20871 though it may be worth looking at why licm and indvars combine to generate 65-bit multiplies in that test. Patch by Riyaz V Puthiyapurayil Reviewers: craig.topper, schweitz Reviewed By: craig.topper, schweitz Subscribers: RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D38668 llvm-svn: 316254
2017-10-21 10:26:00 +08:00
; X32-NEXT: movl %edi, 4(%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
; X32-NEXT: movl {{[0-9]+}}(%esp), %edi # 4-byte Reload
[X86] Do not generate __multi3 for mul i128 on X86 Summary: __multi3 is not available on x86 (32-bit). Setting lib call name for MULI_128 to nullptr forces DAGTypeLegalizer::ExpandIntRes_MUL to generate instructions for 128-bit multiply instead of a call to an undefined function. This fixes PR20871 though it may be worth looking at why licm and indvars combine to generate 65-bit multiplies in that test. Patch by Riyaz V Puthiyapurayil Reviewers: craig.topper, schweitz Reviewed By: craig.topper, schweitz Subscribers: RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D38668 llvm-svn: 316254
2017-10-21 10:26:00 +08:00
; X32-NEXT: movl %edi, 8(%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
; X32-NEXT: movl {{[0-9]+}}(%esp), %edi # 4-byte Reload
[X86] Do not generate __multi3 for mul i128 on X86 Summary: __multi3 is not available on x86 (32-bit). Setting lib call name for MULI_128 to nullptr forces DAGTypeLegalizer::ExpandIntRes_MUL to generate instructions for 128-bit multiply instead of a call to an undefined function. This fixes PR20871 though it may be worth looking at why licm and indvars combine to generate 65-bit multiplies in that test. Patch by Riyaz V Puthiyapurayil Reviewers: craig.topper, schweitz Reviewed By: craig.topper, schweitz Subscribers: RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D38668 llvm-svn: 316254
2017-10-21 10:26:00 +08:00
; X32-NEXT: movl %edi, 12(%ecx)
; X32-NEXT: movl %ebx, 16(%ecx)
; X32-NEXT: movl %esi, 20(%ecx)
; X32-NEXT: movl %eax, 24(%ecx)
; X32-NEXT: movl %edx, 28(%ecx)
; X32-NEXT: addl $88, %esp
Correct dwarf unwind information in function epilogue This patch aims to provide correct dwarf unwind information in function epilogue for X86. It consists of two parts. The first part inserts CFI instructions that set appropriate cfa offset and cfa register in emitEpilogue() in X86FrameLowering. This part is X86 specific. The second part is platform independent and ensures that: * CFI instructions do not affect code generation (they are not counted as instructions when tail duplicating or tail merging) * Unwind information remains correct when a function is modified by different passes. This is done in a late pass by analyzing information about cfa offset and cfa register in BBs and inserting additional CFI directives where necessary. Added CFIInstrInserter pass: * analyzes each basic block to determine cfa offset and register are valid at its entry and exit * verifies that outgoing cfa offset and register of predecessor blocks match incoming values of their successors * inserts additional CFI directives at basic block beginning to correct the rule for calculating CFA Having CFI instructions in function epilogue can cause incorrect CFA calculation rule for some basic blocks. This can happen if, due to basic block reordering, or the existence of multiple epilogue blocks, some of the blocks have wrong cfa offset and register values set by the epilogue block above them. CFIInstrInserter is currently run only on X86, but can be used by any target that implements support for adding CFI instructions in epilogue. Patch by Violeta Vukobrat. Differential Revision: https://reviews.llvm.org/D42848 llvm-svn: 330706
2018-04-24 18:32:08 +08:00
; X32-NEXT: .cfi_def_cfa_offset 20
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: popl %esi
Correct dwarf unwind information in function epilogue This patch aims to provide correct dwarf unwind information in function epilogue for X86. It consists of two parts. The first part inserts CFI instructions that set appropriate cfa offset and cfa register in emitEpilogue() in X86FrameLowering. This part is X86 specific. The second part is platform independent and ensures that: * CFI instructions do not affect code generation (they are not counted as instructions when tail duplicating or tail merging) * Unwind information remains correct when a function is modified by different passes. This is done in a late pass by analyzing information about cfa offset and cfa register in BBs and inserting additional CFI directives where necessary. Added CFIInstrInserter pass: * analyzes each basic block to determine cfa offset and register are valid at its entry and exit * verifies that outgoing cfa offset and register of predecessor blocks match incoming values of their successors * inserts additional CFI directives at basic block beginning to correct the rule for calculating CFA Having CFI instructions in function epilogue can cause incorrect CFA calculation rule for some basic blocks. This can happen if, due to basic block reordering, or the existence of multiple epilogue blocks, some of the blocks have wrong cfa offset and register values set by the epilogue block above them. CFIInstrInserter is currently run only on X86, but can be used by any target that implements support for adding CFI instructions in epilogue. Patch by Violeta Vukobrat. Differential Revision: https://reviews.llvm.org/D42848 llvm-svn: 330706
2018-04-24 18:32:08 +08:00
; X32-NEXT: .cfi_def_cfa_offset 16
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: popl %edi
Correct dwarf unwind information in function epilogue This patch aims to provide correct dwarf unwind information in function epilogue for X86. It consists of two parts. The first part inserts CFI instructions that set appropriate cfa offset and cfa register in emitEpilogue() in X86FrameLowering. This part is X86 specific. The second part is platform independent and ensures that: * CFI instructions do not affect code generation (they are not counted as instructions when tail duplicating or tail merging) * Unwind information remains correct when a function is modified by different passes. This is done in a late pass by analyzing information about cfa offset and cfa register in BBs and inserting additional CFI directives where necessary. Added CFIInstrInserter pass: * analyzes each basic block to determine cfa offset and register are valid at its entry and exit * verifies that outgoing cfa offset and register of predecessor blocks match incoming values of their successors * inserts additional CFI directives at basic block beginning to correct the rule for calculating CFA Having CFI instructions in function epilogue can cause incorrect CFA calculation rule for some basic blocks. This can happen if, due to basic block reordering, or the existence of multiple epilogue blocks, some of the blocks have wrong cfa offset and register values set by the epilogue block above them. CFIInstrInserter is currently run only on X86, but can be used by any target that implements support for adding CFI instructions in epilogue. Patch by Violeta Vukobrat. Differential Revision: https://reviews.llvm.org/D42848 llvm-svn: 330706
2018-04-24 18:32:08 +08:00
; X32-NEXT: .cfi_def_cfa_offset 12
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: popl %ebx
Correct dwarf unwind information in function epilogue This patch aims to provide correct dwarf unwind information in function epilogue for X86. It consists of two parts. The first part inserts CFI instructions that set appropriate cfa offset and cfa register in emitEpilogue() in X86FrameLowering. This part is X86 specific. The second part is platform independent and ensures that: * CFI instructions do not affect code generation (they are not counted as instructions when tail duplicating or tail merging) * Unwind information remains correct when a function is modified by different passes. This is done in a late pass by analyzing information about cfa offset and cfa register in BBs and inserting additional CFI directives where necessary. Added CFIInstrInserter pass: * analyzes each basic block to determine cfa offset and register are valid at its entry and exit * verifies that outgoing cfa offset and register of predecessor blocks match incoming values of their successors * inserts additional CFI directives at basic block beginning to correct the rule for calculating CFA Having CFI instructions in function epilogue can cause incorrect CFA calculation rule for some basic blocks. This can happen if, due to basic block reordering, or the existence of multiple epilogue blocks, some of the blocks have wrong cfa offset and register values set by the epilogue block above them. CFIInstrInserter is currently run only on X86, but can be used by any target that implements support for adding CFI instructions in epilogue. Patch by Violeta Vukobrat. Differential Revision: https://reviews.llvm.org/D42848 llvm-svn: 330706
2018-04-24 18:32:08 +08:00
; X32-NEXT: .cfi_def_cfa_offset 8
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: popl %ebp
Correct dwarf unwind information in function epilogue This patch aims to provide correct dwarf unwind information in function epilogue for X86. It consists of two parts. The first part inserts CFI instructions that set appropriate cfa offset and cfa register in emitEpilogue() in X86FrameLowering. This part is X86 specific. The second part is platform independent and ensures that: * CFI instructions do not affect code generation (they are not counted as instructions when tail duplicating or tail merging) * Unwind information remains correct when a function is modified by different passes. This is done in a late pass by analyzing information about cfa offset and cfa register in BBs and inserting additional CFI directives where necessary. Added CFIInstrInserter pass: * analyzes each basic block to determine cfa offset and register are valid at its entry and exit * verifies that outgoing cfa offset and register of predecessor blocks match incoming values of their successors * inserts additional CFI directives at basic block beginning to correct the rule for calculating CFA Having CFI instructions in function epilogue can cause incorrect CFA calculation rule for some basic blocks. This can happen if, due to basic block reordering, or the existence of multiple epilogue blocks, some of the blocks have wrong cfa offset and register values set by the epilogue block above them. CFIInstrInserter is currently run only on X86, but can be used by any target that implements support for adding CFI instructions in epilogue. Patch by Violeta Vukobrat. Differential Revision: https://reviews.llvm.org/D42848 llvm-svn: 330706
2018-04-24 18:32:08 +08:00
; X32-NEXT: .cfi_def_cfa_offset 4
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: retl
;
; X64-LABEL: test:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; X64: # %bb.0: # %entry
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: pushq %r15
; X64-NEXT: .cfi_def_cfa_offset 16
; X64-NEXT: pushq %r14
; 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: .cfi_def_cfa_offset 32
[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: .cfi_offset %r14, -24
; 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
Correct dwarf unwind information in function epilogue This patch aims to provide correct dwarf unwind information in function epilogue for X86. It consists of two parts. The first part inserts CFI instructions that set appropriate cfa offset and cfa register in emitEpilogue() in X86FrameLowering. This part is X86 specific. The second part is platform independent and ensures that: * CFI instructions do not affect code generation (they are not counted as instructions when tail duplicating or tail merging) * Unwind information remains correct when a function is modified by different passes. This is done in a late pass by analyzing information about cfa offset and cfa register in BBs and inserting additional CFI directives where necessary. Added CFIInstrInserter pass: * analyzes each basic block to determine cfa offset and register are valid at its entry and exit * verifies that outgoing cfa offset and register of predecessor blocks match incoming values of their successors * inserts additional CFI directives at basic block beginning to correct the rule for calculating CFA Having CFI instructions in function epilogue can cause incorrect CFA calculation rule for some basic blocks. This can happen if, due to basic block reordering, or the existence of multiple epilogue blocks, some of the blocks have wrong cfa offset and register values set by the epilogue block above them. CFIInstrInserter is currently run only on X86, but can be used by any target that implements support for adding CFI instructions in epilogue. Patch by Violeta Vukobrat. Differential Revision: https://reviews.llvm.org/D42848 llvm-svn: 330706
2018-04-24 18:32:08 +08:00
; X64-NEXT: .cfi_def_cfa_offset 24
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 %r14
Correct dwarf unwind information in function epilogue This patch aims to provide correct dwarf unwind information in function epilogue for X86. It consists of two parts. The first part inserts CFI instructions that set appropriate cfa offset and cfa register in emitEpilogue() in X86FrameLowering. This part is X86 specific. The second part is platform independent and ensures that: * CFI instructions do not affect code generation (they are not counted as instructions when tail duplicating or tail merging) * Unwind information remains correct when a function is modified by different passes. This is done in a late pass by analyzing information about cfa offset and cfa register in BBs and inserting additional CFI directives where necessary. Added CFIInstrInserter pass: * analyzes each basic block to determine cfa offset and register are valid at its entry and exit * verifies that outgoing cfa offset and register of predecessor blocks match incoming values of their successors * inserts additional CFI directives at basic block beginning to correct the rule for calculating CFA Having CFI instructions in function epilogue can cause incorrect CFA calculation rule for some basic blocks. This can happen if, due to basic block reordering, or the existence of multiple epilogue blocks, some of the blocks have wrong cfa offset and register values set by the epilogue block above them. CFIInstrInserter is currently run only on X86, but can be used by any target that implements support for adding CFI instructions in epilogue. Patch by Violeta Vukobrat. Differential Revision: https://reviews.llvm.org/D42848 llvm-svn: 330706
2018-04-24 18:32:08 +08:00
; X64-NEXT: .cfi_def_cfa_offset 16
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 %r15
Correct dwarf unwind information in function epilogue This patch aims to provide correct dwarf unwind information in function epilogue for X86. It consists of two parts. The first part inserts CFI instructions that set appropriate cfa offset and cfa register in emitEpilogue() in X86FrameLowering. This part is X86 specific. The second part is platform independent and ensures that: * CFI instructions do not affect code generation (they are not counted as instructions when tail duplicating or tail merging) * Unwind information remains correct when a function is modified by different passes. This is done in a late pass by analyzing information about cfa offset and cfa register in BBs and inserting additional CFI directives where necessary. Added CFIInstrInserter pass: * analyzes each basic block to determine cfa offset and register are valid at its entry and exit * verifies that outgoing cfa offset and register of predecessor blocks match incoming values of their successors * inserts additional CFI directives at basic block beginning to correct the rule for calculating CFA Having CFI instructions in function epilogue can cause incorrect CFA calculation rule for some basic blocks. This can happen if, due to basic block reordering, or the existence of multiple epilogue blocks, some of the blocks have wrong cfa offset and register values set by the epilogue block above them. CFIInstrInserter is currently run only on X86, but can be used by any target that implements support for adding CFI instructions in epilogue. Patch by Violeta Vukobrat. Differential Revision: https://reviews.llvm.org/D42848 llvm-svn: 330706
2018-04-24 18:32:08 +08:00
; X64-NEXT: .cfi_def_cfa_offset 8
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: 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
}
[X86] Remove target feature info from mul-i256.ll test. NFC. llvm-svn: 303558
2017-05-22 23:04:08 +08:00
attributes #0 = { norecurse nounwind uwtable }