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.
22 lines
782 B
LLVM
22 lines
782 B
LLVM
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
|
|
; RUN: llc < %s -mtriple=x86_64-- -mcpu=corei7 | FileCheck %s
|
|
|
|
define void @autogen_SD31033(ptr %a0) {
|
|
; CHECK-LABEL: autogen_SD31033:
|
|
; CHECK: # %bb.0: # %BB
|
|
; CHECK-NEXT: .p2align 4
|
|
; CHECK-NEXT: .LBB0_1: # %CF
|
|
; CHECK-NEXT: # =>This Inner Loop Header: Depth=1
|
|
; CHECK-NEXT: jmp .LBB0_1
|
|
BB:
|
|
%L5 = load i16, ptr %a0
|
|
%I8 = insertelement <4 x i16> zeroinitializer, i16 %L5, i32 1
|
|
%Tr = trunc <4 x i16> %I8 to <4 x i1>
|
|
%Shuff28 = shufflevector <4 x i1> zeroinitializer, <4 x i1> %Tr, <4 x i32> <i32 undef, i32 3, i32 5, i32 undef>
|
|
br label %CF
|
|
|
|
CF: ; preds = %CF, %BB
|
|
%E42 = extractelement <4 x i1> %Shuff28, i32 3
|
|
br label %CF
|
|
}
|