llvm-project/llvm/test/CodeGen/X86/2006-08-21-ExtraMovInst.ll
Jeremy Morse e6bf48d110
[X86] Don't request 0x90 nop filling in p2align directives (#110134)
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.
2024-10-02 11:14:05 +01:00

31 lines
1.0 KiB
LLVM

; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
; RUN: llc < %s -mtriple=i686-- -mcpu=i386 | FileCheck %s
define i32 @foo(i32 %t, i32 %C) {
; CHECK-LABEL: foo:
; CHECK: # %bb.0: # %entry
; CHECK-NEXT: movl {{[0-9]+}}(%esp), %ecx
; CHECK-NEXT: movl {{[0-9]+}}(%esp), %eax
; CHECK-NEXT: decl %eax
; CHECK-NEXT: .p2align 4
; CHECK-NEXT: .LBB0_1: # %cond_true
; CHECK-NEXT: # =>This Inner Loop Header: Depth=1
; CHECK-NEXT: incl %eax
; CHECK-NEXT: cmpl $40, %ecx
; CHECK-NEXT: jl .LBB0_1
; CHECK-NEXT: # %bb.2: # %bb12
; CHECK-NEXT: retl
entry:
br label %cond_true
cond_true: ; preds = %cond_true, %entry
%t_addr.0.0 = phi i32 [ %t, %entry ], [ %tmp7, %cond_true ] ; <i32> [#uses=2]
%tmp7 = add i32 %t_addr.0.0, 1 ; <i32> [#uses=1]
%tmp = icmp sgt i32 %C, 39 ; <i1> [#uses=1]
br i1 %tmp, label %bb12, label %cond_true
bb12: ; preds = %cond_true
ret i32 %t_addr.0.0
}