Hi,
In the InstCombinePass, by default the pass will try to sink an instruction to its successor basic block when possible (so that the instruction isn’t executed on path where its result isn’t needed.). But doing that it will also increase a value’s live range. For example:
entry:
..
%6 = load float, ..
%s.0 = load float, ..
%mul22 = fmul float %6, %s.0
%add23 = fadd float %mul22, zeroinitializer
%7 = load float, ..
%s.1 = load float, ..
%mul26 = fmul float %7, %s.1
%add27 = fadd float %add23, %mul26
..
br i1 %cmp, label %cleanup, label %if.end1
if.end1:
%15 = load float, ..
%add67 = fadd %add27, %15
store float %add67, ..
br label %cleanup
cleanup:
return
In the original input, only %add27
has longer live range, but after InstCombine with instcombine-code-sinking=true (default), it turns out that %6, %s.0, %7, %s.1
are having longer live ranges.
entry:
..
%6 = load float, ..
%s.0 = load float, ..
%7 = load float, ..
%s.1 = load float, ..
..
br i1 %cmp, label %cleanup, label %if.end1
if.end1:
%mul22 = fmul float %6, %s.0
%add23 = fadd float %mul22, zeroinitializer
%mul26 = fmul float %7, %s.1
%add27 = fadd float %add23, %mul26
%15 = load float, ..
%add67 = fadd %add27, %15
store float %add67, ..
br label %cleanup
cleanup:
return
We see an issue which cause our customized register-allocator keeping those values like %6, %s.0, %7, %s.1
in registers with a long period.
My questions are:
-
Does llvm expect backend’s instruction scheduler and register allocator can handle this properly?
-
Does this can be solved by llvm’s GlobalISel?
Thank you!
CY