e6bf48d110
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.
36 lines
1.0 KiB
LLVM
36 lines
1.0 KiB
LLVM
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
|
|
; RUN: llc < %s -mtriple=i686-- | FileCheck %s
|
|
|
|
define void @foo(i32 %n, ptr nocapture %p) nounwind {
|
|
; CHECK-LABEL: foo:
|
|
; CHECK: # %bb.0:
|
|
; CHECK-NEXT: movl {{[0-9]+}}(%esp), %eax
|
|
; CHECK-NEXT: movl {{[0-9]+}}(%esp), %ecx
|
|
; CHECK-NEXT: .p2align 4
|
|
; CHECK-NEXT: .LBB0_1: # %bb
|
|
; CHECK-NEXT: # =>This Inner Loop Header: Depth=1
|
|
; CHECK-NEXT: fldl (%eax,%ecx,8)
|
|
; CHECK-NEXT: fmull {{\.?LCPI[0-9]+_[0-9]+}}
|
|
; CHECK-NEXT: fstpl (%eax,%ecx,8)
|
|
; CHECK-NEXT: decl %ecx
|
|
; CHECK-NEXT: js .LBB0_1
|
|
; CHECK-NEXT: # %bb.2: # %return
|
|
; CHECK-NEXT: retl
|
|
br label %bb
|
|
|
|
bb:
|
|
%indvar = phi i32 [ 0, %0 ], [ %indvar.next, %bb ]
|
|
%i.03 = sub i32 %n, %indvar
|
|
%1 = getelementptr double, ptr %p, i32 %i.03
|
|
%2 = load double, ptr %1, align 4
|
|
%3 = fmul double %2, 2.930000e+00
|
|
store double %3, ptr %1, align 4
|
|
%4 = add i32 %i.03, -1
|
|
%phitmp = icmp slt i32 %4, 0
|
|
%indvar.next = add i32 %indvar, 1
|
|
br i1 %phitmp, label %bb, label %return
|
|
|
|
return:
|
|
ret void
|
|
}
|