e6bf48d110
As of revea222be0d, LLVMs assembler will actually try to honour the "fill value" part of p2align directives. X86 printed these as 0x90, which isn't actually what it wanted: we want multi-byte nops for .text padding. Compiling via a textual assembly file produces single-byte nop padding sinceea222be0dbut the built-in assembler will produce multi-byte nops. This divergent behaviour is undesirable. To fix: don't set the byte padding field for x86, which allows the assembler to pick multi-byte nops. Test that we get the same multi-byte padding when compiled via textual assembly or directly to object file. Added same-align-bytes-with-llasm-llobj.ll to that effect, updated numerous other tests to not contain check-lines for the explicit padding.
36 lines
1.1 KiB
LLVM
36 lines
1.1 KiB
LLVM
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
|
|
; RUN: llc < %s -mtriple=x86_64-linux | FileCheck %s
|
|
|
|
; This is a case where we would incorrectly conclude that LBB0_1 could only
|
|
; be reached via fall through and would therefore omit the label.
|
|
|
|
@g = dso_local global i32 0
|
|
|
|
define dso_local void @xyz() {
|
|
; CHECK-LABEL: xyz:
|
|
; CHECK: # %bb.0: # %entry
|
|
; CHECK-NEXT: movl $g, %eax
|
|
; CHECK-NEXT: movq %rax, %xmm0
|
|
; CHECK-NEXT: xorpd %xmm1, %xmm1
|
|
; CHECK-NEXT: ucomisd %xmm1, %xmm0
|
|
; CHECK-NEXT: jne .LBB0_1
|
|
; CHECK-NEXT: jnp .LBB0_2
|
|
; CHECK-NEXT: .p2align 4
|
|
; CHECK-NEXT: .LBB0_1: # %foo
|
|
; CHECK-NEXT: # =>This Inner Loop Header: Depth=1
|
|
; CHECK-NEXT: ucomisd %xmm1, %xmm0
|
|
; CHECK-NEXT: ja .LBB0_1
|
|
; CHECK-NEXT: .LBB0_2: # %bar
|
|
; CHECK-NEXT: retq
|
|
entry:
|
|
%cmp1 = fcmp oeq double bitcast (i64 ptrtoint (ptr @g to i64) to double), 0.000000e+00
|
|
br i1 %cmp1, label %bar, label %foo
|
|
|
|
foo:
|
|
%cmp2 = fcmp ogt double bitcast (i64 ptrtoint (ptr @g to i64) to double), 0.000000e+00
|
|
br i1 %cmp2, label %foo, label %bar
|
|
|
|
bar:
|
|
ret void
|
|
}
|