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.
31 lines
951 B
LLVM
31 lines
951 B
LLVM
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
|
|
; RUN: llc < %s -mtriple=x86_64-unknown-linux-gnu | FileCheck %s
|
|
|
|
define void @PR33747(ptr nocapture) {
|
|
; CHECK-LABEL: PR33747:
|
|
; CHECK: # %bb.0:
|
|
; CHECK-NEXT: movl 24(%rdi), %eax
|
|
; CHECK-NEXT: leal 1(%rax), %ecx
|
|
; CHECK-NEXT: cmpl $3, %ecx
|
|
; CHECK-NEXT: setb %cl
|
|
; CHECK-NEXT: testl %eax, %eax
|
|
; CHECK-NEXT: setne %al
|
|
; CHECK-NEXT: testb %cl, %al
|
|
; CHECK-NEXT: je .LBB0_2
|
|
; CHECK-NEXT: .p2align 4
|
|
; CHECK-NEXT: .LBB0_1: # =>This Inner Loop Header: Depth=1
|
|
; CHECK-NEXT: jmp .LBB0_1
|
|
; CHECK-NEXT: .p2align 4
|
|
; CHECK-NEXT: .LBB0_2: # =>This Inner Loop Header: Depth=1
|
|
; CHECK-NEXT: jmp .LBB0_2
|
|
%2 = getelementptr inbounds i32, ptr %0, i64 6
|
|
%3 = load i32, ptr %2, align 4
|
|
%4 = add i32 %3, 1
|
|
%5 = icmp ult i32 %4, 3
|
|
%6 = icmp ne i32 %3, 0
|
|
%7 = and i1 %6, %5
|
|
br i1 %7, label %8, label %9
|
|
br label %8
|
|
br label %9
|
|
}
|