
As of rev ea222be0d, 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 since ea222be0d but 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.
25 lines
649 B
LLVM
25 lines
649 B
LLVM
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py UTC_ARGS: --version 3
|
|
; RUN: llc < %s -mtriple=x86_64-- | FileCheck %s
|
|
|
|
define i32 @main(i1 %arg) {
|
|
; CHECK-LABEL: main:
|
|
; CHECK: # %bb.0: # %bb
|
|
; CHECK-NEXT: .p2align 4
|
|
; CHECK-NEXT: .LBB0_1: # %bb1
|
|
; CHECK-NEXT: # =>This Inner Loop Header: Depth=1
|
|
; CHECK-NEXT: jmp .LBB0_1
|
|
bb:
|
|
br label %bb1
|
|
|
|
bb1:
|
|
%i = phi i64 [ 0, %bb ], [ %i8, %bb1 ]
|
|
%i2 = add i32 1, 1
|
|
%i3 = icmp eq i32 %i2, 0
|
|
%i4 = add i32 0, 1
|
|
%i5 = icmp eq i32 %i4, 0
|
|
%i6 = select i1 %arg, i1 %i5, i1 %i3
|
|
%i7 = and i64 %i, 0
|
|
%i8 = select i1 %i6, i64 0, i64 %i
|
|
br label %bb1
|
|
}
|