RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-23 13:02:52 +02:00
Code Issues Projects Releases Wiki Activity
2c6ef18647
llvm-mirror/test/CodeGen/X86/pr32284.ll

595 lines
19 KiB
LLVM
Raw Normal View History

[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
[FastISel] Disable local value sinking by default This is causing compilation timeouts on code with long sequences of local values and calls (i.e. foo(1); foo(2); foo(3); ...). It turns out that code coverage instrumentation is a great way to create sequences like this, which how our users ran into the issue in practice. Intel has a tool that detects these kinds of non-linear compile time issues, and Andy Kaylor reported it as PR37010. The current sinking code scans the whole basic block once per local value sink, which happens before emitting each call. In theory, local values should only be introduced to be used by instructions between the current flush point and the last flush point, so we should only need to scan those instructions. llvm-svn: 329822
2018-04-11 18:03:07 +02:00
; RUN: llc -fast-isel-sink-local-values -O0 -mtriple=x86_64-unknown -mcpu=skx -o - %s | FileCheck %s --check-prefix=X86-O0
; RUN: llc -fast-isel-sink-local-values -mtriple=x86_64-unknown -mcpu=skx -o - %s | FileCheck %s --check-prefix=X64
; RUN: llc -fast-isel-sink-local-values -O0 -mtriple=i686-unknown -mcpu=skx -o - %s | FileCheck %s --check-prefix=686-O0
; RUN: llc -fast-isel-sink-local-values -mtriple=i686-unknown -mcpu=skx -o - %s | FileCheck %s --check-prefix=686
[SDAG] Fix zeroExtend assertion error Move CombineTo preventing deleted node from being returned in visitZERO_EXTEND. Fixes PR32284. Reviewers: RKSimon, bogner Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31254 llvm-svn: 298604
2017-03-23 16:01:50 +01:00
@c = external constant i8, align 1
define void @foo() {
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; X86-O0-LABEL: foo:
[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-04 18:18:51 +01:00
; X86-O0: # %bb.0: # %entry
[X86] Remove AVX512 early out from X86FastISel::X86SelectCmp. This shouldn't be needed anymore since i1 isn't a legal type. llvm-svn: 316912
2017-10-30 15:50:11 +01:00
; X86-O0-NEXT: xorl %eax, %eax
; X86-O0-NEXT: movl %eax, %ecx
; X86-O0-NEXT: xorl %eax, %eax
; X86-O0-NEXT: movzbl c, %edx
; X86-O0-NEXT: subl %edx, %eax
; X86-O0-NEXT: movslq %eax, %rsi
; X86-O0-NEXT: subq %rsi, %rcx
; X86-O0-NEXT: movb %cl, %dil
; X86-O0-NEXT: cmpb $0, %dil
; X86-O0-NEXT: setne %dil
; X86-O0-NEXT: andb $1, %dil
; X86-O0-NEXT: movb %dil, -{{[0-9]+}}(%rsp)
; X86-O0-NEXT: cmpb $0, c
; X86-O0-NEXT: setne %dil
; X86-O0-NEXT: xorb $-1, %dil
; X86-O0-NEXT: xorb $-1, %dil
; X86-O0-NEXT: andb $1, %dil
; X86-O0-NEXT: movzbl %dil, %eax
; X86-O0-NEXT: movzbl c, %edx
; X86-O0-NEXT: cmpl %edx, %eax
; X86-O0-NEXT: setle %dil
; X86-O0-NEXT: andb $1, %dil
; X86-O0-NEXT: movzbl %dil, %eax
; X86-O0-NEXT: movl %eax, -{{[0-9]+}}(%rsp)
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; X86-O0-NEXT: retq
;
; X64-LABEL: foo:
[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-04 18:18:51 +01:00
; X64: # %bb.0: # %entry
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; X64-NEXT: movzbl {{.*}}(%rip), %eax
; X64-NEXT: xorl %ecx, %ecx
; X64-NEXT: testl %eax, %eax
; X64-NEXT: setne %cl
[DAGCombiner] Set the right SDLoc on extended SETCC uses (7/N) ExtendSetCCUses updates SETCC nodes which use a load (OriginalLoad) to reflect a simplification to the load (ExtLoad). Based on my reading, ExtendSetCCUses may create new nodes to extend a constant attached to a SETCC. It also creates fresh SETCC nodes which refer to any updated operands. ISTM that the location applied to the new constant and SETCC nodes should be the same as the location of the ExtLoad. This was suggested by Adrian in https://reviews.llvm.org/D45995. Part of: llvm.org/PR37262 Differential Revision: https://reviews.llvm.org/D46216 llvm-svn: 332119
2018-05-11 20:40:10 +02:00
; X64-NEXT: testb %al, %al
; X64-NEXT: setne -{{[0-9]+}}(%rsp)
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; X64-NEXT: xorl %edx, %edx
; X64-NEXT: cmpl %eax, %ecx
; X64-NEXT: setle %dl
; X64-NEXT: movl %edx, -{{[0-9]+}}(%rsp)
; X64-NEXT: retq
;
; 686-O0-LABEL: foo:
[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-04 18:18:51 +01:00
; 686-O0: # %bb.0: # %entry
[X86] Remove AVX512 early out from X86FastISel::X86SelectCmp. This shouldn't be needed anymore since i1 isn't a legal type. llvm-svn: 316912
2017-10-30 15:50:11 +01:00
; 686-O0-NEXT: subl $8, %esp
; 686-O0-NEXT: .cfi_def_cfa_offset 12
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-O0-NEXT: movb c, %al
[X86] Remove AVX512 early out from X86FastISel::X86SelectCmp. This shouldn't be needed anymore since i1 isn't a legal type. llvm-svn: 316912
2017-10-30 15:50:11 +01:00
; 686-O0-NEXT: cmpb $0, %al
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-O0-NEXT: setne %al
[X86] Remove AVX512 early out from X86FastISel::X86SelectCmp. This shouldn't be needed anymore since i1 isn't a legal type. llvm-svn: 316912
2017-10-30 15:50:11 +01:00
; 686-O0-NEXT: andb $1, %al
; 686-O0-NEXT: movb %al, {{[0-9]+}}(%esp)
; 686-O0-NEXT: cmpb $0, c
; 686-O0-NEXT: setne %al
; 686-O0-NEXT: xorb $-1, %al
; 686-O0-NEXT: xorb $-1, %al
; 686-O0-NEXT: andb $1, %al
; 686-O0-NEXT: movzbl %al, %ecx
; 686-O0-NEXT: movzbl c, %edx
; 686-O0-NEXT: cmpl %edx, %ecx
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-O0-NEXT: setle %al
; 686-O0-NEXT: andb $1, %al
; 686-O0-NEXT: movzbl %al, %ecx
[X86] Remove AVX512 early out from X86FastISel::X86SelectCmp. This shouldn't be needed anymore since i1 isn't a legal type. llvm-svn: 316912
2017-10-30 15:50:11 +01:00
; 686-O0-NEXT: movl %ecx, (%esp)
; 686-O0-NEXT: addl $8, %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 12:32:08 +02:00
; 686-O0-NEXT: .cfi_def_cfa_offset 4
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-O0-NEXT: retl
;
; 686-LABEL: foo:
[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-04 18:18:51 +01:00
; 686: # %bb.0: # %entry
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-NEXT: subl $8, %esp
; 686-NEXT: .cfi_def_cfa_offset 12
; 686-NEXT: movzbl c, %eax
; 686-NEXT: xorl %ecx, %ecx
; 686-NEXT: testl %eax, %eax
; 686-NEXT: setne %cl
; 686-NEXT: testb %al, %al
; 686-NEXT: setne {{[0-9]+}}(%esp)
; 686-NEXT: xorl %edx, %edx
; 686-NEXT: cmpl %eax, %ecx
; 686-NEXT: setle %dl
; 686-NEXT: movl %edx, {{[0-9]+}}(%esp)
; 686-NEXT: addl $8, %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 12:32:08 +02:00
; 686-NEXT: .cfi_def_cfa_offset 4
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-NEXT: retl
[SDAG] Fix zeroExtend assertion error Move CombineTo preventing deleted node from being returned in visitZERO_EXTEND. Fixes PR32284. Reviewers: RKSimon, bogner Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31254 llvm-svn: 298604
2017-03-23 16:01:50 +01:00
entry:
%a = alloca i8, align 1
%b = alloca i32, align 4
%0 = load i8, i8* @c, align 1
%conv = zext i8 %0 to i32
%sub = sub nsw i32 0, %conv
%conv1 = sext i32 %sub to i64
%sub2 = sub nsw i64 0, %conv1
%conv3 = trunc i64 %sub2 to i8
%tobool = icmp ne i8 %conv3, 0
%frombool = zext i1 %tobool to i8
store i8 %frombool, i8* %a, align 1
%1 = load i8, i8* @c, align 1
%tobool4 = icmp ne i8 %1, 0
%lnot = xor i1 %tobool4, true
%lnot5 = xor i1 %lnot, true
%conv6 = zext i1 %lnot5 to i32
%2 = load i8, i8* @c, align 1
%conv7 = zext i8 %2 to i32
%cmp = icmp sle i32 %conv6, %conv7
%conv8 = zext i1 %cmp to i32
store i32 %conv8, i32* %b, align 4
ret void
}
[SDAG] Fix CombineTo ordering in visitZERO_EXTEND and visitSIGN_EXTEND Reorder CombineTo Calls to prevent references to stale/deleted SDNodes which caused undue assertions. Reviewers: dbabokin Subscribers: aemerson, rengolin, llvm-commits Differential Revision: https://reviews.llvm.org/D31625 llvm-svn: 304460
2017-06-01 21:33:50 +02:00
@var_5 = external global i32, align 4
@var_57 = external global i64, align 8
@_ZN8struct_210member_2_0E = external global i64, align 8
define void @f1() {
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; X86-O0-LABEL: f1:
[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-04 18:18:51 +01:00
; X86-O0: # %bb.0: # %entry
[FastISel] Sink local value materializations to first use Summary: Local values are constants, global addresses, and stack addresses that can't be folded into the instruction that uses them. For example, when storing the address of a global variable into memory, we need to materialize that address into a register. FastISel doesn't want to materialize any given local value more than once, so it generates all local value materialization code at EmitStartPt, which always dominates the current insertion point. This allows it to maintain a map of local value registers, and it knows that the local value area will always dominate the current insertion point. The downside is that local value instructions are always emitted without a source location. This is done to prevent jumpy line tables, but it means that the local value area will be considered part of the previous statement. Consider this C code: call1(); // line 1 ++global; // line 2 ++global; // line 3 call2(&global, &local); // line 4 Today we end up with assembly and line tables like this: .loc 1 1 callq call1 leaq global(%rip), %rdi leaq local(%rsp), %rsi .loc 1 2 addq $1, global(%rip) .loc 1 3 addq $1, global(%rip) .loc 1 4 callq call2 The LEA instructions in the local value area have no source location and are treated as being on line 1. Stepping through the code in a debugger and correlating it with the assembly won't make much sense, because these materializations are only required for line 4. This is actually problematic for the VS debugger "set next statement" feature, which effectively assumes that there are no registers live across statement boundaries. By sinking the local value code into the statement and fixing up the source location, we can make that feature work. This was filed as https://bugs.llvm.org/show_bug.cgi?id=35975 and https://crbug.com/793819. This change is obviously not enough to make this feature work reliably in all cases, but I felt that it was worth doing anyway because it usually generates smaller, more comprehensible -O0 code. I measured a 0.12% regression in code generation time with LLC on the sqlite3 amalgamation, so I think this is worth doing. There are some special cases worth calling out in the commit message: 1. local values materialized for phis 2. local values used by no-op casts 3. dead local value code Local values can be materialized for phis, and this does not show up as a vreg use in MachineRegisterInfo. In this case, if there are no other uses, this patch sinks the value to the first terminator, EH label, or the end of the BB if nothing else exists. Local values may also be used by no-op casts, which adds the register to the RegFixups table. Without reversing the RegFixups map direction, we don't have enough information to sink these instructions. Lastly, if the local value register has no other uses, we can delete it. This comes up when fastisel tries two instruction selection approaches and the first materializes the value but fails and the second succeeds without using the local value. Reviewers: aprantl, dblaikie, qcolombet, MatzeB, vsk, echristo Subscribers: dotdash, chandlerc, hans, sdardis, amccarth, javed.absar, zturner, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D43093 llvm-svn: 327581
2018-03-14 22:54:21 +01:00
; X86-O0-NEXT: movslq var_5, %rax
; X86-O0-NEXT: movabsq $8381627093, %rcx # imm = 0x1F3957AD5
; X86-O0-NEXT: addq %rcx, %rax
; X86-O0-NEXT: cmpq $0, %rax
[X86] Remove AVX512 early out from X86FastISel::X86SelectCmp. This shouldn't be needed anymore since i1 isn't a legal type. llvm-svn: 316912
2017-10-30 15:50:11 +01:00
; X86-O0-NEXT: setne %dl
; X86-O0-NEXT: andb $1, %dl
; X86-O0-NEXT: movb %dl, -{{[0-9]+}}(%rsp)
; X86-O0-NEXT: movl var_5, %esi
; X86-O0-NEXT: xorl $-1, %esi
; X86-O0-NEXT: cmpl $0, %esi
; X86-O0-NEXT: setne %dl
; X86-O0-NEXT: xorb $-1, %dl
; X86-O0-NEXT: andb $1, %dl
; X86-O0-NEXT: movzbl %dl, %esi
; X86-O0-NEXT: movl %esi, %eax
; X86-O0-NEXT: movslq var_5, %rcx
; X86-O0-NEXT: addq $7093, %rcx # imm = 0x1BB5
; X86-O0-NEXT: cmpq %rcx, %rax
; X86-O0-NEXT: setg %dl
; X86-O0-NEXT: andb $1, %dl
; X86-O0-NEXT: movzbl %dl, %esi
; X86-O0-NEXT: movl %esi, %eax
; X86-O0-NEXT: movq %rax, var_57
; X86-O0-NEXT: movl var_5, %esi
; X86-O0-NEXT: xorl $-1, %esi
; X86-O0-NEXT: cmpl $0, %esi
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; X86-O0-NEXT: setne %dl
; X86-O0-NEXT: xorb $-1, %dl
; X86-O0-NEXT: andb $1, %dl
[X86] Remove AVX512 early out from X86FastISel::X86SelectCmp. This shouldn't be needed anymore since i1 isn't a legal type. llvm-svn: 316912
2017-10-30 15:50:11 +01:00
; X86-O0-NEXT: movzbl %dl, %esi
; X86-O0-NEXT: movl %esi, %eax
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; X86-O0-NEXT: movq %rax, _ZN8struct_210member_2_0E
; X86-O0-NEXT: retq
;
; X64-LABEL: f1:
[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-04 18:18:51 +01:00
; X64: # %bb.0: # %entry
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; X64-NEXT: movslq {{.*}}(%rip), %rax
[DAGCombiner] Set the right SDLoc on extended SETCC uses (7/N) ExtendSetCCUses updates SETCC nodes which use a load (OriginalLoad) to reflect a simplification to the load (ExtLoad). Based on my reading, ExtendSetCCUses may create new nodes to extend a constant attached to a SETCC. It also creates fresh SETCC nodes which refer to any updated operands. ISTM that the location applied to the new constant and SETCC nodes should be the same as the location of the ExtLoad. This was suggested by Adrian in https://reviews.llvm.org/D45995. Part of: llvm.org/PR37262 Differential Revision: https://reviews.llvm.org/D46216 llvm-svn: 332119
2018-05-11 20:40:10 +02:00
; X64-NEXT: movabsq $-8381627093, %rcx # imm = 0xFFFFFFFE0C6A852B
; X64-NEXT: cmpq %rcx, %rax
; X64-NEXT: setne -{{[0-9]+}}(%rsp)
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; X64-NEXT: xorl %ecx, %ecx
; X64-NEXT: cmpq $-1, %rax
; X64-NEXT: sete %cl
; X64-NEXT: xorl %edx, %edx
; X64-NEXT: cmpl $-1, %eax
; X64-NEXT: sete %dl
; X64-NEXT: addq $7093, %rax # imm = 0x1BB5
; X64-NEXT: xorl %esi, %esi
; X64-NEXT: cmpq %rax, %rdx
; X64-NEXT: setg %sil
; X64-NEXT: movq %rsi, {{.*}}(%rip)
; X64-NEXT: movq %rcx, {{.*}}(%rip)
; X64-NEXT: retq
;
; 686-O0-LABEL: f1:
[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-04 18:18:51 +01:00
; 686-O0: # %bb.0: # %entry
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-O0-NEXT: pushl %ebp
; 686-O0-NEXT: .cfi_def_cfa_offset 8
; 686-O0-NEXT: pushl %ebx
; 686-O0-NEXT: .cfi_def_cfa_offset 12
; 686-O0-NEXT: pushl %edi
; 686-O0-NEXT: .cfi_def_cfa_offset 16
; 686-O0-NEXT: pushl %esi
; 686-O0-NEXT: .cfi_def_cfa_offset 20
[DAGCombine] Disable finding better chains for stores at O0 Unoptimized IR can have linear sequences of stores to an array, where the initial GEP for the first store is formed from the pointer to the array, and the GEP for each store after the first is formed from the previous GEP with some offset in an inductive fashion. The (large) resulting DAG when analyzed by DAGCombine undergoes an excessive number of combines as each store node is examined every time its' offset node is combined with any child of the offset. One of the transformations is findBetterNeighborChains which assists MergeConsecutiveStores. The former relies on repeated chain walking to do its' work, however MergeConsecutiveStores is disabled at O0 which makes the transformation redundant. Any optimization level other than O0 would invoke InstCombine which would resolve the chain of GEPs into flat base + offset GEP for each store which does not exhibit the repeated examination of each store to the array. Disabling this optimization fixes an excessive compile time issue (30~ minutes for the test case provided) at O0. Reviewers: niravd, craig.topper, t.p.northover Differential Revision: https://reviews.llvm.org/D40193 llvm-svn: 319142
2017-11-28 05:07:59 +01:00
; 686-O0-NEXT: subl $24, %esp
; 686-O0-NEXT: .cfi_def_cfa_offset 44
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-O0-NEXT: .cfi_offset %esi, -20
; 686-O0-NEXT: .cfi_offset %edi, -16
; 686-O0-NEXT: .cfi_offset %ebx, -12
; 686-O0-NEXT: .cfi_offset %ebp, -8
; 686-O0-NEXT: movl var_5, %eax
; 686-O0-NEXT: movl %eax, %ecx
; 686-O0-NEXT: sarl $31, %ecx
[DAGCombine] Disable finding better chains for stores at O0 Unoptimized IR can have linear sequences of stores to an array, where the initial GEP for the first store is formed from the pointer to the array, and the GEP for each store after the first is formed from the previous GEP with some offset in an inductive fashion. The (large) resulting DAG when analyzed by DAGCombine undergoes an excessive number of combines as each store node is examined every time its' offset node is combined with any child of the offset. One of the transformations is findBetterNeighborChains which assists MergeConsecutiveStores. The former relies on repeated chain walking to do its' work, however MergeConsecutiveStores is disabled at O0 which makes the transformation redundant. Any optimization level other than O0 would invoke InstCombine which would resolve the chain of GEPs into flat base + offset GEP for each store which does not exhibit the repeated examination of each store to the array. Disabling this optimization fixes an excessive compile time issue (30~ minutes for the test case provided) at O0. Reviewers: niravd, craig.topper, t.p.northover Differential Revision: https://reviews.llvm.org/D40193 llvm-svn: 319142
2017-11-28 05:07:59 +01:00
; 686-O0-NEXT: xorl $208307499, %eax # imm = 0xC6A852B
; 686-O0-NEXT: xorl $-2, %ecx
; 686-O0-NEXT: orl %ecx, %eax
; 686-O0-NEXT: setne {{[0-9]+}}(%esp)
; 686-O0-NEXT: movl var_5, %ecx
; 686-O0-NEXT: movl %ecx, %edx
[DAGCombiner] Set the right SDLoc on a newly-created sextload (6/N) This teaches tryToFoldExtOfLoad to set the right location on a newly-created extload. With that in place, the logic for performing a certain ([s|z]ext (load ...)) combine becomes identical for sexts and zexts, and we can get rid of one copy of the logic. The test case churn is due to dependencies on IROrders inherited from the wrong SDLoc. Part of: llvm.org/PR37262 Differential Revision: https://reviews.llvm.org/D46158 llvm-svn: 332118
2018-05-11 20:40:08 +02:00
; 686-O0-NEXT: sarl $31, %edx
; 686-O0-NEXT: movl %ecx, %esi
; 686-O0-NEXT: subl $-1, %esi
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-O0-NEXT: sete %bl
[DAGCombiner] Set the right SDLoc on a newly-created sextload (6/N) This teaches tryToFoldExtOfLoad to set the right location on a newly-created extload. With that in place, the logic for performing a certain ([s|z]ext (load ...)) combine becomes identical for sexts and zexts, and we can get rid of one copy of the logic. The test case churn is due to dependencies on IROrders inherited from the wrong SDLoc. Part of: llvm.org/PR37262 Differential Revision: https://reviews.llvm.org/D46158 llvm-svn: 332118
2018-05-11 20:40:08 +02:00
; 686-O0-NEXT: movzbl %bl, %edi
[DAGCombine] Disable finding better chains for stores at O0 Unoptimized IR can have linear sequences of stores to an array, where the initial GEP for the first store is formed from the pointer to the array, and the GEP for each store after the first is formed from the previous GEP with some offset in an inductive fashion. The (large) resulting DAG when analyzed by DAGCombine undergoes an excessive number of combines as each store node is examined every time its' offset node is combined with any child of the offset. One of the transformations is findBetterNeighborChains which assists MergeConsecutiveStores. The former relies on repeated chain walking to do its' work, however MergeConsecutiveStores is disabled at O0 which makes the transformation redundant. Any optimization level other than O0 would invoke InstCombine which would resolve the chain of GEPs into flat base + offset GEP for each store which does not exhibit the repeated examination of each store to the array. Disabling this optimization fixes an excessive compile time issue (30~ minutes for the test case provided) at O0. Reviewers: niravd, craig.topper, t.p.northover Differential Revision: https://reviews.llvm.org/D40193 llvm-svn: 319142
2017-11-28 05:07:59 +01:00
; 686-O0-NEXT: xorl %ebp, %ebp
; 686-O0-NEXT: addl $7093, %ecx # imm = 0x1BB5
[DAGCombiner] Set the right SDLoc on a newly-created sextload (6/N) This teaches tryToFoldExtOfLoad to set the right location on a newly-created extload. With that in place, the logic for performing a certain ([s|z]ext (load ...)) combine becomes identical for sexts and zexts, and we can get rid of one copy of the logic. The test case churn is due to dependencies on IROrders inherited from the wrong SDLoc. Part of: llvm.org/PR37262 Differential Revision: https://reviews.llvm.org/D46158 llvm-svn: 332118
2018-05-11 20:40:08 +02:00
; 686-O0-NEXT: adcxl %ebp, %edx
; 686-O0-NEXT: subl %edi, %ecx
; 686-O0-NEXT: sbbl $0, %edx
[DAGCombine] Disable finding better chains for stores at O0 Unoptimized IR can have linear sequences of stores to an array, where the initial GEP for the first store is formed from the pointer to the array, and the GEP for each store after the first is formed from the previous GEP with some offset in an inductive fashion. The (large) resulting DAG when analyzed by DAGCombine undergoes an excessive number of combines as each store node is examined every time its' offset node is combined with any child of the offset. One of the transformations is findBetterNeighborChains which assists MergeConsecutiveStores. The former relies on repeated chain walking to do its' work, however MergeConsecutiveStores is disabled at O0 which makes the transformation redundant. Any optimization level other than O0 would invoke InstCombine which would resolve the chain of GEPs into flat base + offset GEP for each store which does not exhibit the repeated examination of each store to the array. Disabling this optimization fixes an excessive compile time issue (30~ minutes for the test case provided) at O0. Reviewers: niravd, craig.topper, t.p.northover Differential Revision: https://reviews.llvm.org/D40193 llvm-svn: 319142
2017-11-28 05:07:59 +01:00
; 686-O0-NEXT: setl %bl
[DAGCombiner] Set the right SDLoc on a newly-created sextload (6/N) This teaches tryToFoldExtOfLoad to set the right location on a newly-created extload. With that in place, the logic for performing a certain ([s|z]ext (load ...)) combine becomes identical for sexts and zexts, and we can get rid of one copy of the logic. The test case churn is due to dependencies on IROrders inherited from the wrong SDLoc. Part of: llvm.org/PR37262 Differential Revision: https://reviews.llvm.org/D46158 llvm-svn: 332118
2018-05-11 20:40:08 +02:00
; 686-O0-NEXT: movzbl %bl, %edi
; 686-O0-NEXT: movl %edi, var_57
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-O0-NEXT: movl $0, var_57+4
[DAGCombiner] Set the right SDLoc on a newly-created sextload (6/N) This teaches tryToFoldExtOfLoad to set the right location on a newly-created extload. With that in place, the logic for performing a certain ([s|z]ext (load ...)) combine becomes identical for sexts and zexts, and we can get rid of one copy of the logic. The test case churn is due to dependencies on IROrders inherited from the wrong SDLoc. Part of: llvm.org/PR37262 Differential Revision: https://reviews.llvm.org/D46158 llvm-svn: 332118
2018-05-11 20:40:08 +02:00
; 686-O0-NEXT: movl var_5, %edi
; 686-O0-NEXT: subl $-1, %edi
[DAGCombine] Disable finding better chains for stores at O0 Unoptimized IR can have linear sequences of stores to an array, where the initial GEP for the first store is formed from the pointer to the array, and the GEP for each store after the first is formed from the previous GEP with some offset in an inductive fashion. The (large) resulting DAG when analyzed by DAGCombine undergoes an excessive number of combines as each store node is examined every time its' offset node is combined with any child of the offset. One of the transformations is findBetterNeighborChains which assists MergeConsecutiveStores. The former relies on repeated chain walking to do its' work, however MergeConsecutiveStores is disabled at O0 which makes the transformation redundant. Any optimization level other than O0 would invoke InstCombine which would resolve the chain of GEPs into flat base + offset GEP for each store which does not exhibit the repeated examination of each store to the array. Disabling this optimization fixes an excessive compile time issue (30~ minutes for the test case provided) at O0. Reviewers: niravd, craig.topper, t.p.northover Differential Revision: https://reviews.llvm.org/D40193 llvm-svn: 319142
2017-11-28 05:07:59 +01:00
; 686-O0-NEXT: sete %bl
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-O0-NEXT: movzbl %bl, %ebp
; 686-O0-NEXT: movl %ebp, _ZN8struct_210member_2_0E
; 686-O0-NEXT: movl $0, _ZN8struct_210member_2_0E+4
[DAGCombiner] Set the right SDLoc on a newly-created sextload (6/N) This teaches tryToFoldExtOfLoad to set the right location on a newly-created extload. With that in place, the logic for performing a certain ([s|z]ext (load ...)) combine becomes identical for sexts and zexts, and we can get rid of one copy of the logic. The test case churn is due to dependencies on IROrders inherited from the wrong SDLoc. Part of: llvm.org/PR37262 Differential Revision: https://reviews.llvm.org/D46158 llvm-svn: 332118
2018-05-11 20:40:08 +02:00
; 686-O0-NEXT: movl %eax, {{[-0-9]+}}(%e{{[sb]}}p) # 4-byte Spill
; 686-O0-NEXT: movl %esi, {{[-0-9]+}}(%e{{[sb]}}p) # 4-byte Spill
; 686-O0-NEXT: movl %ecx, {{[-0-9]+}}(%e{{[sb]}}p) # 4-byte Spill
; 686-O0-NEXT: movl %edx, {{[-0-9]+}}(%e{{[sb]}}p) # 4-byte Spill
; 686-O0-NEXT: movl %edi, (%esp) # 4-byte Spill
[DAGCombine] Disable finding better chains for stores at O0 Unoptimized IR can have linear sequences of stores to an array, where the initial GEP for the first store is formed from the pointer to the array, and the GEP for each store after the first is formed from the previous GEP with some offset in an inductive fashion. The (large) resulting DAG when analyzed by DAGCombine undergoes an excessive number of combines as each store node is examined every time its' offset node is combined with any child of the offset. One of the transformations is findBetterNeighborChains which assists MergeConsecutiveStores. The former relies on repeated chain walking to do its' work, however MergeConsecutiveStores is disabled at O0 which makes the transformation redundant. Any optimization level other than O0 would invoke InstCombine which would resolve the chain of GEPs into flat base + offset GEP for each store which does not exhibit the repeated examination of each store to the array. Disabling this optimization fixes an excessive compile time issue (30~ minutes for the test case provided) at O0. Reviewers: niravd, craig.topper, t.p.northover Differential Revision: https://reviews.llvm.org/D40193 llvm-svn: 319142
2017-11-28 05:07:59 +01:00
; 686-O0-NEXT: addl $24, %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 12:32:08 +02:00
; 686-O0-NEXT: .cfi_def_cfa_offset 20
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-O0-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 12:32:08 +02:00
; 686-O0-NEXT: .cfi_def_cfa_offset 16
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-O0-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 12:32:08 +02:00
; 686-O0-NEXT: .cfi_def_cfa_offset 12
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-O0-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 12:32:08 +02:00
; 686-O0-NEXT: .cfi_def_cfa_offset 8
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-O0-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 12:32:08 +02:00
; 686-O0-NEXT: .cfi_def_cfa_offset 4
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-O0-NEXT: retl
;
; 686-LABEL: f1:
[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-04 18:18:51 +01:00
; 686: # %bb.0: # %entry
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-NEXT: pushl %edi
; 686-NEXT: .cfi_def_cfa_offset 8
; 686-NEXT: pushl %esi
; 686-NEXT: .cfi_def_cfa_offset 12
; 686-NEXT: subl $1, %esp
; 686-NEXT: .cfi_def_cfa_offset 13
; 686-NEXT: .cfi_offset %esi, -12
; 686-NEXT: .cfi_offset %edi, -8
; 686-NEXT: movl var_5, %edx
[DAGCombiner] Set the right SDLoc on extended SETCC uses (7/N) ExtendSetCCUses updates SETCC nodes which use a load (OriginalLoad) to reflect a simplification to the load (ExtLoad). Based on my reading, ExtendSetCCUses may create new nodes to extend a constant attached to a SETCC. It also creates fresh SETCC nodes which refer to any updated operands. ISTM that the location applied to the new constant and SETCC nodes should be the same as the location of the ExtLoad. This was suggested by Adrian in https://reviews.llvm.org/D45995. Part of: llvm.org/PR37262 Differential Revision: https://reviews.llvm.org/D46216 llvm-svn: 332119
2018-05-11 20:40:10 +02:00
; 686-NEXT: movl %edx, %eax
; 686-NEXT: xorl $208307499, %eax # imm = 0xC6A852B
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-NEXT: movl %edx, %esi
; 686-NEXT: sarl $31, %esi
[DAGCombiner] Set the right SDLoc on extended SETCC uses (7/N) ExtendSetCCUses updates SETCC nodes which use a load (OriginalLoad) to reflect a simplification to the load (ExtLoad). Based on my reading, ExtendSetCCUses may create new nodes to extend a constant attached to a SETCC. It also creates fresh SETCC nodes which refer to any updated operands. ISTM that the location applied to the new constant and SETCC nodes should be the same as the location of the ExtLoad. This was suggested by Adrian in https://reviews.llvm.org/D45995. Part of: llvm.org/PR37262 Differential Revision: https://reviews.llvm.org/D46216 llvm-svn: 332119
2018-05-11 20:40:10 +02:00
; 686-NEXT: movl %esi, %ecx
; 686-NEXT: xorl $-2, %ecx
; 686-NEXT: orl %eax, %ecx
; 686-NEXT: setne (%esp)
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-NEXT: movl %edx, %ecx
; 686-NEXT: andl %esi, %ecx
; 686-NEXT: xorl %eax, %eax
; 686-NEXT: cmpl $-1, %ecx
; 686-NEXT: sete %al
; 686-NEXT: xorl %ecx, %ecx
; 686-NEXT: cmpl $-1, %edx
; 686-NEXT: sete %cl
; 686-NEXT: xorl %edi, %edi
; 686-NEXT: addl $7093, %edx # imm = 0x1BB5
; 686-NEXT: adcxl %edi, %esi
; 686-NEXT: cmpl %ecx, %edx
; 686-NEXT: sbbl $0, %esi
; 686-NEXT: setl %cl
; 686-NEXT: movzbl %cl, %ecx
; 686-NEXT: movl %ecx, var_57
; 686-NEXT: movl $0, var_57+4
; 686-NEXT: movl %eax, _ZN8struct_210member_2_0E
; 686-NEXT: movl $0, _ZN8struct_210member_2_0E+4
; 686-NEXT: addl $1, %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 12:32:08 +02:00
; 686-NEXT: .cfi_def_cfa_offset 12
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-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 12:32:08 +02:00
; 686-NEXT: .cfi_def_cfa_offset 8
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-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 12:32:08 +02:00
; 686-NEXT: .cfi_def_cfa_offset 4
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-NEXT: retl
[SDAG] Fix CombineTo ordering in visitZERO_EXTEND and visitSIGN_EXTEND Reorder CombineTo Calls to prevent references to stale/deleted SDNodes which caused undue assertions. Reviewers: dbabokin Subscribers: aemerson, rengolin, llvm-commits Differential Revision: https://reviews.llvm.org/D31625 llvm-svn: 304460
2017-06-01 21:33:50 +02:00
entry:
%a = alloca i8, align 1
%0 = load i32, i32* @var_5, align 4
%conv = sext i32 %0 to i64
%add = add nsw i64 %conv, 8381627093
%tobool = icmp ne i64 %add, 0
%frombool = zext i1 %tobool to i8
store i8 %frombool, i8* %a, align 1
%1 = load i32, i32* @var_5, align 4
%neg = xor i32 %1, -1
%tobool1 = icmp ne i32 %neg, 0
%lnot = xor i1 %tobool1, true
%conv2 = zext i1 %lnot to i64
%2 = load i32, i32* @var_5, align 4
%conv3 = sext i32 %2 to i64
%add4 = add nsw i64 %conv3, 7093
%cmp = icmp sgt i64 %conv2, %add4
%conv5 = zext i1 %cmp to i64
store i64 %conv5, i64* @var_57, align 8
%3 = load i32, i32* @var_5, align 4
%neg6 = xor i32 %3, -1
%tobool7 = icmp ne i32 %neg6, 0
%lnot8 = xor i1 %tobool7, true
%conv9 = zext i1 %lnot8 to i64
store i64 %conv9, i64* @_ZN8struct_210member_2_0E, align 8
ret void
}
@var_7 = external global i8, align 1
define void @f2() {
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; X86-O0-LABEL: f2:
[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-04 18:18:51 +01:00
; X86-O0: # %bb.0: # %entry
[FastISel] Sink local value materializations to first use Summary: Local values are constants, global addresses, and stack addresses that can't be folded into the instruction that uses them. For example, when storing the address of a global variable into memory, we need to materialize that address into a register. FastISel doesn't want to materialize any given local value more than once, so it generates all local value materialization code at EmitStartPt, which always dominates the current insertion point. This allows it to maintain a map of local value registers, and it knows that the local value area will always dominate the current insertion point. The downside is that local value instructions are always emitted without a source location. This is done to prevent jumpy line tables, but it means that the local value area will be considered part of the previous statement. Consider this C code: call1(); // line 1 ++global; // line 2 ++global; // line 3 call2(&global, &local); // line 4 Today we end up with assembly and line tables like this: .loc 1 1 callq call1 leaq global(%rip), %rdi leaq local(%rsp), %rsi .loc 1 2 addq $1, global(%rip) .loc 1 3 addq $1, global(%rip) .loc 1 4 callq call2 The LEA instructions in the local value area have no source location and are treated as being on line 1. Stepping through the code in a debugger and correlating it with the assembly won't make much sense, because these materializations are only required for line 4. This is actually problematic for the VS debugger "set next statement" feature, which effectively assumes that there are no registers live across statement boundaries. By sinking the local value code into the statement and fixing up the source location, we can make that feature work. This was filed as https://bugs.llvm.org/show_bug.cgi?id=35975 and https://crbug.com/793819. This change is obviously not enough to make this feature work reliably in all cases, but I felt that it was worth doing anyway because it usually generates smaller, more comprehensible -O0 code. I measured a 0.12% regression in code generation time with LLC on the sqlite3 amalgamation, so I think this is worth doing. There are some special cases worth calling out in the commit message: 1. local values materialized for phis 2. local values used by no-op casts 3. dead local value code Local values can be materialized for phis, and this does not show up as a vreg use in MachineRegisterInfo. In this case, if there are no other uses, this patch sinks the value to the first terminator, EH label, or the end of the BB if nothing else exists. Local values may also be used by no-op casts, which adds the register to the RegFixups table. Without reversing the RegFixups map direction, we don't have enough information to sink these instructions. Lastly, if the local value register has no other uses, we can delete it. This comes up when fastisel tries two instruction selection approaches and the first materializes the value but fails and the second succeeds without using the local value. Reviewers: aprantl, dblaikie, qcolombet, MatzeB, vsk, echristo Subscribers: dotdash, chandlerc, hans, sdardis, amccarth, javed.absar, zturner, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D43093 llvm-svn: 327581
2018-03-14 22:54:21 +01:00
; X86-O0-NEXT: movzbl var_7, %eax
[X86] Remove AVX512 early out from X86FastISel::X86SelectCmp. This shouldn't be needed anymore since i1 isn't a legal type. llvm-svn: 316912
2017-10-30 15:50:11 +01:00
; X86-O0-NEXT: cmpb $0, var_7
[FastISel] Sink local value materializations to first use Summary: Local values are constants, global addresses, and stack addresses that can't be folded into the instruction that uses them. For example, when storing the address of a global variable into memory, we need to materialize that address into a register. FastISel doesn't want to materialize any given local value more than once, so it generates all local value materialization code at EmitStartPt, which always dominates the current insertion point. This allows it to maintain a map of local value registers, and it knows that the local value area will always dominate the current insertion point. The downside is that local value instructions are always emitted without a source location. This is done to prevent jumpy line tables, but it means that the local value area will be considered part of the previous statement. Consider this C code: call1(); // line 1 ++global; // line 2 ++global; // line 3 call2(&global, &local); // line 4 Today we end up with assembly and line tables like this: .loc 1 1 callq call1 leaq global(%rip), %rdi leaq local(%rsp), %rsi .loc 1 2 addq $1, global(%rip) .loc 1 3 addq $1, global(%rip) .loc 1 4 callq call2 The LEA instructions in the local value area have no source location and are treated as being on line 1. Stepping through the code in a debugger and correlating it with the assembly won't make much sense, because these materializations are only required for line 4. This is actually problematic for the VS debugger "set next statement" feature, which effectively assumes that there are no registers live across statement boundaries. By sinking the local value code into the statement and fixing up the source location, we can make that feature work. This was filed as https://bugs.llvm.org/show_bug.cgi?id=35975 and https://crbug.com/793819. This change is obviously not enough to make this feature work reliably in all cases, but I felt that it was worth doing anyway because it usually generates smaller, more comprehensible -O0 code. I measured a 0.12% regression in code generation time with LLC on the sqlite3 amalgamation, so I think this is worth doing. There are some special cases worth calling out in the commit message: 1. local values materialized for phis 2. local values used by no-op casts 3. dead local value code Local values can be materialized for phis, and this does not show up as a vreg use in MachineRegisterInfo. In this case, if there are no other uses, this patch sinks the value to the first terminator, EH label, or the end of the BB if nothing else exists. Local values may also be used by no-op casts, which adds the register to the RegFixups table. Without reversing the RegFixups map direction, we don't have enough information to sink these instructions. Lastly, if the local value register has no other uses, we can delete it. This comes up when fastisel tries two instruction selection approaches and the first materializes the value but fails and the second succeeds without using the local value. Reviewers: aprantl, dblaikie, qcolombet, MatzeB, vsk, echristo Subscribers: dotdash, chandlerc, hans, sdardis, amccarth, javed.absar, zturner, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D43093 llvm-svn: 327581
2018-03-14 22:54:21 +01:00
; X86-O0-NEXT: setne %cl
; X86-O0-NEXT: xorb $-1, %cl
; X86-O0-NEXT: andb $1, %cl
; X86-O0-NEXT: movzbl %cl, %edx
; X86-O0-NEXT: xorl %edx, %eax
; X86-O0-NEXT: movw %ax, %si
; X86-O0-NEXT: movw %si, -{{[0-9]+}}(%rsp)
; X86-O0-NEXT: movzbl var_7, %eax
; X86-O0-NEXT: movw %ax, %si
; X86-O0-NEXT: cmpw $0, %si
; X86-O0-NEXT: setne %cl
; X86-O0-NEXT: xorb $-1, %cl
; X86-O0-NEXT: andb $1, %cl
; X86-O0-NEXT: movzbl %cl, %eax
; X86-O0-NEXT: movzbl var_7, %edx
; X86-O0-NEXT: cmpl %edx, %eax
; X86-O0-NEXT: sete %cl
; X86-O0-NEXT: andb $1, %cl
; X86-O0-NEXT: movzbl %cl, %eax
; X86-O0-NEXT: movw %ax, %si
; X86-O0-NEXT: # implicit-def: $rdi
; X86-O0-NEXT: movw %si, (%rdi)
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; X86-O0-NEXT: retq
;
; X64-LABEL: f2:
[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-04 18:18:51 +01:00
; X64: # %bb.0: # %entry
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; X64-NEXT: movzbl {{.*}}(%rip), %eax
; X64-NEXT: xorl %ecx, %ecx
; X64-NEXT: testl %eax, %eax
; X64-NEXT: sete %cl
; X64-NEXT: xorl %eax, %ecx
; X64-NEXT: movw %cx, -{{[0-9]+}}(%rsp)
; X64-NEXT: xorl %ecx, %ecx
; X64-NEXT: testb %al, %al
; X64-NEXT: sete %cl
; X64-NEXT: xorl %edx, %edx
; X64-NEXT: cmpl %eax, %ecx
; X64-NEXT: sete %dl
; X64-NEXT: movw %dx, (%rax)
; X64-NEXT: retq
;
; 686-O0-LABEL: f2:
[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-04 18:18:51 +01:00
; 686-O0: # %bb.0: # %entry
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-O0-NEXT: pushl %esi
[FastISel] Sink local value materializations to first use Summary: Local values are constants, global addresses, and stack addresses that can't be folded into the instruction that uses them. For example, when storing the address of a global variable into memory, we need to materialize that address into a register. FastISel doesn't want to materialize any given local value more than once, so it generates all local value materialization code at EmitStartPt, which always dominates the current insertion point. This allows it to maintain a map of local value registers, and it knows that the local value area will always dominate the current insertion point. The downside is that local value instructions are always emitted without a source location. This is done to prevent jumpy line tables, but it means that the local value area will be considered part of the previous statement. Consider this C code: call1(); // line 1 ++global; // line 2 ++global; // line 3 call2(&global, &local); // line 4 Today we end up with assembly and line tables like this: .loc 1 1 callq call1 leaq global(%rip), %rdi leaq local(%rsp), %rsi .loc 1 2 addq $1, global(%rip) .loc 1 3 addq $1, global(%rip) .loc 1 4 callq call2 The LEA instructions in the local value area have no source location and are treated as being on line 1. Stepping through the code in a debugger and correlating it with the assembly won't make much sense, because these materializations are only required for line 4. This is actually problematic for the VS debugger "set next statement" feature, which effectively assumes that there are no registers live across statement boundaries. By sinking the local value code into the statement and fixing up the source location, we can make that feature work. This was filed as https://bugs.llvm.org/show_bug.cgi?id=35975 and https://crbug.com/793819. This change is obviously not enough to make this feature work reliably in all cases, but I felt that it was worth doing anyway because it usually generates smaller, more comprehensible -O0 code. I measured a 0.12% regression in code generation time with LLC on the sqlite3 amalgamation, so I think this is worth doing. There are some special cases worth calling out in the commit message: 1. local values materialized for phis 2. local values used by no-op casts 3. dead local value code Local values can be materialized for phis, and this does not show up as a vreg use in MachineRegisterInfo. In this case, if there are no other uses, this patch sinks the value to the first terminator, EH label, or the end of the BB if nothing else exists. Local values may also be used by no-op casts, which adds the register to the RegFixups table. Without reversing the RegFixups map direction, we don't have enough information to sink these instructions. Lastly, if the local value register has no other uses, we can delete it. This comes up when fastisel tries two instruction selection approaches and the first materializes the value but fails and the second succeeds without using the local value. Reviewers: aprantl, dblaikie, qcolombet, MatzeB, vsk, echristo Subscribers: dotdash, chandlerc, hans, sdardis, amccarth, javed.absar, zturner, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D43093 llvm-svn: 327581
2018-03-14 22:54:21 +01:00
; 686-O0-NEXT: .cfi_def_cfa_offset 8
[X86] Remove AVX512 early out from X86FastISel::X86SelectCmp. This shouldn't be needed anymore since i1 isn't a legal type. llvm-svn: 316912
2017-10-30 15:50:11 +01:00
; 686-O0-NEXT: subl $2, %esp
[FastISel] Sink local value materializations to first use Summary: Local values are constants, global addresses, and stack addresses that can't be folded into the instruction that uses them. For example, when storing the address of a global variable into memory, we need to materialize that address into a register. FastISel doesn't want to materialize any given local value more than once, so it generates all local value materialization code at EmitStartPt, which always dominates the current insertion point. This allows it to maintain a map of local value registers, and it knows that the local value area will always dominate the current insertion point. The downside is that local value instructions are always emitted without a source location. This is done to prevent jumpy line tables, but it means that the local value area will be considered part of the previous statement. Consider this C code: call1(); // line 1 ++global; // line 2 ++global; // line 3 call2(&global, &local); // line 4 Today we end up with assembly and line tables like this: .loc 1 1 callq call1 leaq global(%rip), %rdi leaq local(%rsp), %rsi .loc 1 2 addq $1, global(%rip) .loc 1 3 addq $1, global(%rip) .loc 1 4 callq call2 The LEA instructions in the local value area have no source location and are treated as being on line 1. Stepping through the code in a debugger and correlating it with the assembly won't make much sense, because these materializations are only required for line 4. This is actually problematic for the VS debugger "set next statement" feature, which effectively assumes that there are no registers live across statement boundaries. By sinking the local value code into the statement and fixing up the source location, we can make that feature work. This was filed as https://bugs.llvm.org/show_bug.cgi?id=35975 and https://crbug.com/793819. This change is obviously not enough to make this feature work reliably in all cases, but I felt that it was worth doing anyway because it usually generates smaller, more comprehensible -O0 code. I measured a 0.12% regression in code generation time with LLC on the sqlite3 amalgamation, so I think this is worth doing. There are some special cases worth calling out in the commit message: 1. local values materialized for phis 2. local values used by no-op casts 3. dead local value code Local values can be materialized for phis, and this does not show up as a vreg use in MachineRegisterInfo. In this case, if there are no other uses, this patch sinks the value to the first terminator, EH label, or the end of the BB if nothing else exists. Local values may also be used by no-op casts, which adds the register to the RegFixups table. Without reversing the RegFixups map direction, we don't have enough information to sink these instructions. Lastly, if the local value register has no other uses, we can delete it. This comes up when fastisel tries two instruction selection approaches and the first materializes the value but fails and the second succeeds without using the local value. Reviewers: aprantl, dblaikie, qcolombet, MatzeB, vsk, echristo Subscribers: dotdash, chandlerc, hans, sdardis, amccarth, javed.absar, zturner, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D43093 llvm-svn: 327581
2018-03-14 22:54:21 +01:00
; 686-O0-NEXT: .cfi_def_cfa_offset 10
; 686-O0-NEXT: .cfi_offset %esi, -8
; 686-O0-NEXT: movzbl var_7, %eax
[X86] Remove AVX512 early out from X86FastISel::X86SelectCmp. This shouldn't be needed anymore since i1 isn't a legal type. llvm-svn: 316912
2017-10-30 15:50:11 +01:00
; 686-O0-NEXT: cmpb $0, var_7
[FastISel] Sink local value materializations to first use Summary: Local values are constants, global addresses, and stack addresses that can't be folded into the instruction that uses them. For example, when storing the address of a global variable into memory, we need to materialize that address into a register. FastISel doesn't want to materialize any given local value more than once, so it generates all local value materialization code at EmitStartPt, which always dominates the current insertion point. This allows it to maintain a map of local value registers, and it knows that the local value area will always dominate the current insertion point. The downside is that local value instructions are always emitted without a source location. This is done to prevent jumpy line tables, but it means that the local value area will be considered part of the previous statement. Consider this C code: call1(); // line 1 ++global; // line 2 ++global; // line 3 call2(&global, &local); // line 4 Today we end up with assembly and line tables like this: .loc 1 1 callq call1 leaq global(%rip), %rdi leaq local(%rsp), %rsi .loc 1 2 addq $1, global(%rip) .loc 1 3 addq $1, global(%rip) .loc 1 4 callq call2 The LEA instructions in the local value area have no source location and are treated as being on line 1. Stepping through the code in a debugger and correlating it with the assembly won't make much sense, because these materializations are only required for line 4. This is actually problematic for the VS debugger "set next statement" feature, which effectively assumes that there are no registers live across statement boundaries. By sinking the local value code into the statement and fixing up the source location, we can make that feature work. This was filed as https://bugs.llvm.org/show_bug.cgi?id=35975 and https://crbug.com/793819. This change is obviously not enough to make this feature work reliably in all cases, but I felt that it was worth doing anyway because it usually generates smaller, more comprehensible -O0 code. I measured a 0.12% regression in code generation time with LLC on the sqlite3 amalgamation, so I think this is worth doing. There are some special cases worth calling out in the commit message: 1. local values materialized for phis 2. local values used by no-op casts 3. dead local value code Local values can be materialized for phis, and this does not show up as a vreg use in MachineRegisterInfo. In this case, if there are no other uses, this patch sinks the value to the first terminator, EH label, or the end of the BB if nothing else exists. Local values may also be used by no-op casts, which adds the register to the RegFixups table. Without reversing the RegFixups map direction, we don't have enough information to sink these instructions. Lastly, if the local value register has no other uses, we can delete it. This comes up when fastisel tries two instruction selection approaches and the first materializes the value but fails and the second succeeds without using the local value. Reviewers: aprantl, dblaikie, qcolombet, MatzeB, vsk, echristo Subscribers: dotdash, chandlerc, hans, sdardis, amccarth, javed.absar, zturner, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D43093 llvm-svn: 327581
2018-03-14 22:54:21 +01:00
; 686-O0-NEXT: setne %cl
; 686-O0-NEXT: xorb $-1, %cl
; 686-O0-NEXT: andb $1, %cl
; 686-O0-NEXT: movzbl %cl, %edx
; 686-O0-NEXT: xorl %edx, %eax
; 686-O0-NEXT: movw %ax, %si
; 686-O0-NEXT: movw %si, (%esp)
; 686-O0-NEXT: movzbl var_7, %eax
; 686-O0-NEXT: movw %ax, %si
; 686-O0-NEXT: cmpw $0, %si
; 686-O0-NEXT: setne %cl
; 686-O0-NEXT: xorb $-1, %cl
; 686-O0-NEXT: andb $1, %cl
; 686-O0-NEXT: movzbl %cl, %eax
; 686-O0-NEXT: movzbl var_7, %edx
; 686-O0-NEXT: cmpl %edx, %eax
; 686-O0-NEXT: sete %cl
; 686-O0-NEXT: andb $1, %cl
; 686-O0-NEXT: movzbl %cl, %eax
; 686-O0-NEXT: movw %ax, %si
; 686-O0-NEXT: # implicit-def: $eax
; 686-O0-NEXT: movw %si, (%eax)
[X86] Remove AVX512 early out from X86FastISel::X86SelectCmp. This shouldn't be needed anymore since i1 isn't a legal type. llvm-svn: 316912
2017-10-30 15:50:11 +01:00
; 686-O0-NEXT: addl $2, %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 12:32:08 +02:00
; 686-O0-NEXT: .cfi_def_cfa_offset 8
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-O0-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 12:32:08 +02:00
; 686-O0-NEXT: .cfi_def_cfa_offset 4
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-O0-NEXT: retl
;
; 686-LABEL: f2:
[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-04 18:18:51 +01:00
; 686: # %bb.0: # %entry
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-NEXT: subl $2, %esp
; 686-NEXT: .cfi_def_cfa_offset 6
; 686-NEXT: movzbl var_7, %eax
; 686-NEXT: xorl %ecx, %ecx
; 686-NEXT: testl %eax, %eax
; 686-NEXT: sete %cl
; 686-NEXT: xorl %eax, %ecx
; 686-NEXT: movw %cx, (%esp)
; 686-NEXT: xorl %ecx, %ecx
; 686-NEXT: testb %al, %al
; 686-NEXT: sete %cl
; 686-NEXT: xorl %edx, %edx
; 686-NEXT: cmpl %eax, %ecx
; 686-NEXT: sete %dl
; 686-NEXT: movw %dx, (%eax)
; 686-NEXT: addl $2, %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 12:32:08 +02:00
; 686-NEXT: .cfi_def_cfa_offset 4
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-NEXT: retl
[SDAG] Fix CombineTo ordering in visitZERO_EXTEND and visitSIGN_EXTEND Reorder CombineTo Calls to prevent references to stale/deleted SDNodes which caused undue assertions. Reviewers: dbabokin Subscribers: aemerson, rengolin, llvm-commits Differential Revision: https://reviews.llvm.org/D31625 llvm-svn: 304460
2017-06-01 21:33:50 +02:00
entry:
%a = alloca i16, align 2
%0 = load i8, i8* @var_7, align 1
%conv = zext i8 %0 to i32
%1 = load i8, i8* @var_7, align 1
%tobool = icmp ne i8 %1, 0
%lnot = xor i1 %tobool, true
%conv1 = zext i1 %lnot to i32
%xor = xor i32 %conv, %conv1
%conv2 = trunc i32 %xor to i16
store i16 %conv2, i16* %a, align 2
%2 = load i8, i8* @var_7, align 1
%conv3 = zext i8 %2 to i16
%tobool4 = icmp ne i16 %conv3, 0
%lnot5 = xor i1 %tobool4, true
%conv6 = zext i1 %lnot5 to i32
%3 = load i8, i8* @var_7, align 1
%conv7 = zext i8 %3 to i32
%cmp = icmp eq i32 %conv6, %conv7
%conv8 = zext i1 %cmp to i32
%conv9 = trunc i32 %conv8 to i16
store i16 %conv9, i16* undef, align 2
ret void
}
@var_13 = external global i32, align 4
@var_16 = external global i32, align 4
@var_46 = external global i32, align 4
define void @f3() #0 {
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; X86-O0-LABEL: f3:
[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-04 18:18:51 +01:00
; X86-O0: # %bb.0: # %entry
[X86] Remove AVX512 early out from X86FastISel::X86SelectCmp. This shouldn't be needed anymore since i1 isn't a legal type. llvm-svn: 316912
2017-10-30 15:50:11 +01:00
; X86-O0-NEXT: movl var_13, %eax
; X86-O0-NEXT: xorl $-1, %eax
; X86-O0-NEXT: movl %eax, %eax
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; X86-O0-NEXT: movl %eax, %ecx
[X86] Remove AVX512 early out from X86FastISel::X86SelectCmp. This shouldn't be needed anymore since i1 isn't a legal type. llvm-svn: 316912
2017-10-30 15:50:11 +01:00
; X86-O0-NEXT: cmpl $0, var_13
; X86-O0-NEXT: setne %dl
; X86-O0-NEXT: xorb $-1, %dl
; X86-O0-NEXT: andb $1, %dl
; X86-O0-NEXT: movzbl %dl, %eax
; X86-O0-NEXT: movl %eax, %esi
; X86-O0-NEXT: movl var_13, %eax
; X86-O0-NEXT: xorl $-1, %eax
; X86-O0-NEXT: xorl var_16, %eax
; X86-O0-NEXT: movl %eax, %eax
; X86-O0-NEXT: movl %eax, %edi
; X86-O0-NEXT: andq %rdi, %rsi
; X86-O0-NEXT: orq %rsi, %rcx
; X86-O0-NEXT: movq %rcx, -{{[0-9]+}}(%rsp)
; X86-O0-NEXT: movl var_13, %eax
; X86-O0-NEXT: xorl $-1, %eax
; X86-O0-NEXT: movl %eax, %eax
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; X86-O0-NEXT: movl %eax, %ecx
[X86] Remove AVX512 early out from X86FastISel::X86SelectCmp. This shouldn't be needed anymore since i1 isn't a legal type. llvm-svn: 316912
2017-10-30 15:50:11 +01:00
; X86-O0-NEXT: cmpl $0, var_13
; X86-O0-NEXT: setne %dl
; X86-O0-NEXT: xorb $-1, %dl
; X86-O0-NEXT: andb $1, %dl
; X86-O0-NEXT: movzbl %dl, %eax
; X86-O0-NEXT: movl %eax, %esi
; X86-O0-NEXT: andq $0, %rsi
; X86-O0-NEXT: orq %rsi, %rcx
; X86-O0-NEXT: movl %ecx, %eax
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; X86-O0-NEXT: movl %eax, var_46
; X86-O0-NEXT: retq
;
; X64-LABEL: f3:
[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-04 18:18:51 +01:00
; X64: # %bb.0: # %entry
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; X64-NEXT: movl {{.*}}(%rip), %eax
[X86] Add combine to shrink 64-bit ands when one input is an any_extend and the other input guarantees upper 32 bits are 0. Summary: This gets the shift case from PR35792. Reviewers: spatel, RKSimon Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43222 llvm-svn: 325018
2018-02-13 17:25:25 +01:00
; X64-NEXT: xorl %ecx, %ecx
; X64-NEXT: testl %eax, %eax
; X64-NEXT: notl %eax
; X64-NEXT: sete %cl
; X64-NEXT: movl {{.*}}(%rip), %edx
; X64-NEXT: xorl %eax, %edx
; X64-NEXT: andl %edx, %ecx
; X64-NEXT: orl %eax, %ecx
; X64-NEXT: movq %rcx, -{{[0-9]+}}(%rsp)
; X64-NEXT: movl %eax, {{.*}}(%rip)
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; X64-NEXT: retq
;
; 686-O0-LABEL: f3:
[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-04 18:18:51 +01:00
; 686-O0: # %bb.0: # %entry
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-O0-NEXT: pushl %ebp
; 686-O0-NEXT: .cfi_def_cfa_offset 8
; 686-O0-NEXT: .cfi_offset %ebp, -8
; 686-O0-NEXT: movl %esp, %ebp
; 686-O0-NEXT: .cfi_def_cfa_register %ebp
; 686-O0-NEXT: pushl %edi
; 686-O0-NEXT: pushl %esi
; 686-O0-NEXT: andl $-8, %esp
; 686-O0-NEXT: subl $8, %esp
; 686-O0-NEXT: .cfi_offset %esi, -16
; 686-O0-NEXT: .cfi_offset %edi, -12
; 686-O0-NEXT: movl var_13, %eax
; 686-O0-NEXT: movl %eax, %ecx
; 686-O0-NEXT: notl %ecx
; 686-O0-NEXT: testl %eax, %eax
; 686-O0-NEXT: sete %dl
; 686-O0-NEXT: movzbl %dl, %eax
; 686-O0-NEXT: movl var_16, %esi
; 686-O0-NEXT: movl %ecx, %edi
; 686-O0-NEXT: xorl %esi, %edi
; 686-O0-NEXT: andl %edi, %eax
[DAGCombine] Disable finding better chains for stores at O0 Unoptimized IR can have linear sequences of stores to an array, where the initial GEP for the first store is formed from the pointer to the array, and the GEP for each store after the first is formed from the previous GEP with some offset in an inductive fashion. The (large) resulting DAG when analyzed by DAGCombine undergoes an excessive number of combines as each store node is examined every time its' offset node is combined with any child of the offset. One of the transformations is findBetterNeighborChains which assists MergeConsecutiveStores. The former relies on repeated chain walking to do its' work, however MergeConsecutiveStores is disabled at O0 which makes the transformation redundant. Any optimization level other than O0 would invoke InstCombine which would resolve the chain of GEPs into flat base + offset GEP for each store which does not exhibit the repeated examination of each store to the array. Disabling this optimization fixes an excessive compile time issue (30~ minutes for the test case provided) at O0. Reviewers: niravd, craig.topper, t.p.northover Differential Revision: https://reviews.llvm.org/D40193 llvm-svn: 319142
2017-11-28 05:07:59 +01:00
; 686-O0-NEXT: orl %eax, %ecx
; 686-O0-NEXT: movl %ecx, (%esp)
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-O0-NEXT: movl $0, {{[0-9]+}}(%esp)
[DAGCombine] Disable finding better chains for stores at O0 Unoptimized IR can have linear sequences of stores to an array, where the initial GEP for the first store is formed from the pointer to the array, and the GEP for each store after the first is formed from the previous GEP with some offset in an inductive fashion. The (large) resulting DAG when analyzed by DAGCombine undergoes an excessive number of combines as each store node is examined every time its' offset node is combined with any child of the offset. One of the transformations is findBetterNeighborChains which assists MergeConsecutiveStores. The former relies on repeated chain walking to do its' work, however MergeConsecutiveStores is disabled at O0 which makes the transformation redundant. Any optimization level other than O0 would invoke InstCombine which would resolve the chain of GEPs into flat base + offset GEP for each store which does not exhibit the repeated examination of each store to the array. Disabling this optimization fixes an excessive compile time issue (30~ minutes for the test case provided) at O0. Reviewers: niravd, craig.topper, t.p.northover Differential Revision: https://reviews.llvm.org/D40193 llvm-svn: 319142
2017-11-28 05:07:59 +01:00
; 686-O0-NEXT: movl var_13, %eax
; 686-O0-NEXT: notl %eax
; 686-O0-NEXT: movl %eax, var_46
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-O0-NEXT: leal -8(%ebp), %esp
; 686-O0-NEXT: popl %esi
; 686-O0-NEXT: popl %edi
; 686-O0-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 12:32:08 +02:00
; 686-O0-NEXT: .cfi_def_cfa %esp, 4
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-O0-NEXT: retl
;
; 686-LABEL: f3:
[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-04 18:18:51 +01:00
; 686: # %bb.0: # %entry
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-NEXT: pushl %ebp
; 686-NEXT: .cfi_def_cfa_offset 8
; 686-NEXT: .cfi_offset %ebp, -8
; 686-NEXT: movl %esp, %ebp
; 686-NEXT: .cfi_def_cfa_register %ebp
; 686-NEXT: andl $-8, %esp
; 686-NEXT: subl $8, %esp
; 686-NEXT: movl var_13, %ecx
; 686-NEXT: xorl %eax, %eax
; 686-NEXT: testl %ecx, %ecx
; 686-NEXT: notl %ecx
; 686-NEXT: sete %al
; 686-NEXT: movl var_16, %edx
; 686-NEXT: xorl %ecx, %edx
; 686-NEXT: andl %eax, %edx
[X86] Teach X86TargetLowering::targetShrinkDemandedConstant to set non-demanded bits if it helps created an and mask that can be matched as a zero extend. I had to modify the bswap recognition to allow unshrunk masks to make this work. Fixes PR36689. Differential Revision: https://reviews.llvm.org/D44442 llvm-svn: 327530
2018-03-14 17:55:15 +01:00
; 686-NEXT: orl %ecx, %edx
; 686-NEXT: movl %edx, (%esp)
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-NEXT: movl $0, {{[0-9]+}}(%esp)
; 686-NEXT: movl %ecx, var_46
; 686-NEXT: movl %ebp, %esp
; 686-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 12:32:08 +02:00
; 686-NEXT: .cfi_def_cfa %esp, 4
[X86] Regenerate test using update_llc_test_checks.py llvm-svn: 316911
2017-10-30 15:50:10 +01:00
; 686-NEXT: retl
[SDAG] Fix CombineTo ordering in visitZERO_EXTEND and visitSIGN_EXTEND Reorder CombineTo Calls to prevent references to stale/deleted SDNodes which caused undue assertions. Reviewers: dbabokin Subscribers: aemerson, rengolin, llvm-commits Differential Revision: https://reviews.llvm.org/D31625 llvm-svn: 304460
2017-06-01 21:33:50 +02:00
entry:
%a = alloca i64, align 8
%0 = load i32, i32* @var_13, align 4
%neg = xor i32 %0, -1
%conv = zext i32 %neg to i64
%1 = load i32, i32* @var_13, align 4
%tobool = icmp ne i32 %1, 0
%lnot = xor i1 %tobool, true
%conv1 = zext i1 %lnot to i64
%2 = load i32, i32* @var_13, align 4
%neg2 = xor i32 %2, -1
%3 = load i32, i32* @var_16, align 4
%xor = xor i32 %neg2, %3
%conv3 = zext i32 %xor to i64
%and = and i64 %conv1, %conv3
%or = or i64 %conv, %and
store i64 %or, i64* %a, align 8
%4 = load i32, i32* @var_13, align 4
%neg4 = xor i32 %4, -1
%conv5 = zext i32 %neg4 to i64
%5 = load i32, i32* @var_13, align 4
%tobool6 = icmp ne i32 %5, 0
%lnot7 = xor i1 %tobool6, true
%conv8 = zext i1 %lnot7 to i64
%and9 = and i64 %conv8, 0
%or10 = or i64 %conv5, %and9
%conv11 = trunc i64 %or10 to i32
store i32 %conv11, i32* @var_46, align 4
ret void
}
Reference in New Issue Copy Permalink