[PATCH] D21189: Create subranges for new intervals resulting from live interval splitting

[Matthias Braun via llvm-commits]

MatzeB added a comment.

One thing that still worries me with this patch is that pruneUndefs() is sprinkled around in various LiveRange functions.

I am still worried about the undefs list in the LiveRange class. This is from a maintenance point of view: Are the pruneUndefs() calls necessary for correctness or are they just an optimization? I am not sure all the code uses addSegment()/append()/etc. At the very least there should be some documentation on what it does and when it needs to be called because, as that will not be obvious to people editing the code in the future.
Would it be possible to not save this information in the LiveInterval at all and instead recompute it on demand in the LiveRangeCalc only? That way these complications would be limited to that file. I may experiment with that later.

This should have simpler tests that make the problem obvious. I am currently experimenting with this (still needs some CHECK lines though; Feel free to convert to Hexagon, I was just used to AMDGCN from my previous .mir tests).

  # RUN: llc -march=amdgcn -run-pass liveintervals -debug-only=regalloc -o /dev/null %s 2>&1 | FileCheck %s
  # REQUIRES: asserts
  --- |
    define void @test0() { ret void }
    define void @test1() { ret void }
  ...
  ---
  name: test0
  registers:
    - { id: 0, class: sreg_64 }
  body: |
    bb.0:
      S_NOP 0, implicit-def %0
      S_NOP 0, implicit %0
  
      S_NOP 0, implicit-def undef %0.sub0
      S_NOP 0, implicit %0
  ...
  ---
  name: test1
  registers:
    - { id: 0, class: sreg_64 }
  body: |
    bb.0:
      successors: %bb.1, %bb.2
      S_CBRANCH_VCCNZ %bb.1, implicit undef %vcc
      S_BRANCH %bb.2
  
    bb.1:
      successors: %bb.3
      S_NOP 0, implicit-def undef %0.sub0
      S_BRANCH %bb.3
  
    bb.2:
      successors: %bb.3
      S_NOP 0, implicit-def %0
      S_BRANCH %bb.3
  
    bb.3:
      S_NOP 0
      S_NOP 0, implicit %0
  ...


Repository:
  rL LLVM

https://reviews.llvm.org/D21189