mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-12-27 13:30:05 +00:00
75d77cd179
Summary: Fixes a FIXME in MachineSinking. Instead of using the simple heuristics in isPostDominatedBy, use the real MachinePostDominatorTree and MachineLoopInfo. The old heuristics caused instructions to sink unnecessarily, and might create register pressure. This is the second try of the fix. The first one (D4814) caused a performance regression due to failing to sink instructions out of loops (PR21115). This patch fixes PR21115 by sinking an instruction from a deeper loop to a shallower one regardless of whether the target block post-dominates the source. Thanks Alexey Volkov for reporting PR21115! Test Plan: Added a NVPTX codegen test to verify that our change prevents the backend from over-sinking. It also shows the unnecessary register pressure caused by over-sinking. Added an X86 test to verify we can sink instructions out of loops regardless of the dominance relationship. This test is reduced from Alexey's test in PR21115. Updated an affected test in X86. Also ran SPEC CINT2006 and llvm-test-suite for compilation time and runtime performance. Results are attached separately in the review thread. Reviewers: Jiangning, resistor, hfinkel Reviewed By: hfinkel Subscribers: hfinkel, bruno, volkalexey, llvm-commits, meheff, eliben, jholewinski Differential Revision: http://reviews.llvm.org/D5633 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219773 91177308-0d34-0410-b5e6-96231b3b80d8
41 lines
1.4 KiB
LLVM
41 lines
1.4 KiB
LLVM
; RUN: llc < %s -march=nvptx -mcpu=sm_20 | FileCheck %s
|
|
|
|
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"
|
|
|
|
@scalar1 = internal addrspace(3) global float 0.000000e+00, align 4
|
|
@scalar2 = internal addrspace(3) global float 0.000000e+00, align 4
|
|
|
|
; We shouldn't sink mul.rn.f32 to BB %merge because BB %merge post-dominates
|
|
; BB %entry. Over-sinking created more register pressure on this example. The
|
|
; backend would sink the fmuls to BB %merge, but not the loads for being
|
|
; conservative on sinking memory accesses. As a result, the loads and
|
|
; the two fmuls would be separated to two basic blocks, causing two
|
|
; cross-BB live ranges.
|
|
define float @post_dominate(float %x, i1 %cond) {
|
|
; CHECK-LABEL: post_dominate(
|
|
entry:
|
|
%0 = load float* addrspacecast (float addrspace(3)* @scalar1 to float*), align 4
|
|
%1 = load float* addrspacecast (float addrspace(3)* @scalar2 to float*), align 4
|
|
; CHECK: ld.shared.f32
|
|
; CHECK: ld.shared.f32
|
|
%2 = fmul float %0, %0
|
|
%3 = fmul float %1, %2
|
|
; CHECK-NOT: bra
|
|
; CHECK: mul.rn.f32
|
|
; CHECK: mul.rn.f32
|
|
br i1 %cond, label %then, label %merge
|
|
|
|
then:
|
|
%z = fadd float %x, %x
|
|
br label %then2
|
|
|
|
then2:
|
|
%z2 = fadd float %z, %z
|
|
br label %merge
|
|
|
|
merge:
|
|
%y = phi float [ 0.0, %entry ], [ %z2, %then2 ]
|
|
%w = fadd float %y, %3
|
|
ret float %w
|
|
}
|