1 ; RUN: llc < %s -march=nvptx -mcpu=sm_20 | FileCheck %s 2 3 target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v16:16:16-v32:32:32-v64:64:64-v128:128:128-n16:32:64" 4 5 @scalar1 = internal addrspace(3) global float 0.000000e+00, align 4 6 @scalar2 = internal addrspace(3) global float 0.000000e+00, align 4 7 8 ; We shouldn't sink mul.rn.f32 to BB %merge because BB %merge post-dominates 9 ; BB %entry. Over-sinking created more register pressure on this example. The 10 ; backend would sink the fmuls to BB %merge, but not the loads for being 11 ; conservative on sinking memory accesses. As a result, the loads and 12 ; the two fmuls would be separated to two basic blocks, causing two 13 ; cross-BB live ranges. 14 define float @post_dominate(float %x, i1 %cond) { 15 ; CHECK-LABEL: post_dominate( 16 entry: 17 %0 = load float, float* addrspacecast (float addrspace(3)* @scalar1 to float*), align 4 18 %1 = load float, float* addrspacecast (float addrspace(3)* @scalar2 to float*), align 4 19 ; CHECK: ld.shared.f32 20 ; CHECK: ld.shared.f32 21 %2 = fmul float %0, %0 22 %3 = fmul float %1, %2 23 ; CHECK-NOT: bra 24 ; CHECK: mul.rn.f32 25 ; CHECK: mul.rn.f32 26 br i1 %cond, label %then, label %merge 27 28 then: 29 %z = fadd float %x, %x 30 br label %then2 31 32 then2: 33 %z2 = fadd float %z, %z 34 br label %merge 35 36 merge: 37 %y = phi float [ 0.0, %entry ], [ %z2, %then2 ] 38 %w = fadd float %y, %3 39 ret float %w 40 } 41
