42 lines · plain
1; RUN: llc < %s -mtriple=nvptx64 -mcpu=sm_20 | FileCheck %s2; RUN: %if ptxas %{ llc < %s -mtriple=nvptx64 -mcpu=sm_20 | %ptxas-verify %}3 4target 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"5 6@scalar1 = internal addrspace(3) global float 0.000000e+00, align 47@scalar2 = internal addrspace(3) global float 0.000000e+00, align 48 9; We shouldn't sink mul.rn.f32 to BB %merge because BB %merge post-dominates10; BB %entry. Over-sinking created more register pressure on this example. The11; backend would sink the fmuls to BB %merge, but not the loads for being12; conservative on sinking memory accesses. As a result, the loads and13; the two fmuls would be separated to two basic blocks, causing two14; cross-BB live ranges.15define float @post_dominate(float %x, i1 %cond) {16; CHECK-LABEL: post_dominate(17entry:18 %0 = load float, ptr addrspacecast (ptr addrspace(3) @scalar1 to ptr), align 419 %1 = load float, ptr addrspacecast (ptr addrspace(3) @scalar2 to ptr), align 420; CHECK: ld.shared.b3221; CHECK: ld.shared.b3222 %2 = fmul float %0, %023 %3 = fmul float %1, %224; CHECK-NOT: bra25; CHECK: mul.rn.f3226; CHECK: mul.rn.f3227 br i1 %cond, label %then, label %merge28 29then:30 %z = fadd float %x, %x31 br label %then232 33then2:34 %z2 = fadd float %z, %z35 br label %merge36 37merge:38 %y = phi float [ 0.0, %entry ], [ %z2, %then2 ]39 %w = fadd float %y, %340 ret float %w41}42