Instcombine-code-sinking increases the value's live range

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:

  1. Does llvm expect backend’s instruction scheduler and register allocator can handle this properly?

  2. Does this can be solved by llvm’s GlobalISel?

Thank you!
CY