[PATCH] D91734: [FastISel] Flush local value map on every instruction

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

This causes several regressions in the gdb test suite we're running internally - the failures are:

  FAIL: gdb.base/break.exp: breakpoint at start of multi line while conditional
  FAIL: gdb.base/break.exp: breakpoint info
  FAIL: gdb.base/foll-exec.exp: step through execlp call
  FAIL: gdb.base/foll-exec.exp: step after execlp call
  FAIL: gdb.base/foll-exec.exp: print execd-program/global_i (after execlp)
  FAIL: gdb.base/foll-exec.exp: print execd-program/local_j (after execlp)
  FAIL: gdb.base/foll-exec.exp: print follow-exec/local_k (after execlp)
  FAIL: gdb.base/hbreak2.exp: hardware breakpoint at start of multi line while conditional
  FAIL: gdb.base/hbreak2.exp: hardware breakpoint info

I looked into the first one in break.exp and reduced it a bit, given code like this:

  int main() { }
  int f1(int a, int b) {
    return a && b;
  }

debugging this binary with gdb and running `b f1` results in breaking on an instruction with no line information after this change, eg:
old behavior:

  (gdb) b f1
  Breakpoint 1 at 0x40112c: file test.c, line 2.

new behavior:

  (gdb) b f1
  Breakpoint 1 at 0x40112a

The assembly difference:

  -       xorl    %eax, %eax
  -                                        # kill: def $al killed $al killed $eax
          movl    %edi, -4(%rbp)
          movl    %esi, -8(%rbp)
   .Ltmp2:
  -       .loc    1 3 10 prologue_end             # break.c:3:10
  +       .loc    1 0 0 prologue_end              # break.c:0:0
  +       xorl    %eax, %eax
  +                                        # kill: def $al killed $al killed $eax
  +       .loc    1 3 10                          # break.c:3:10
          cmpl    $0, -4(%rbp)
          movb    %al, -9(%rbp)                   # 1-byte Spill

So it looks like the && caused a location-less zero constant to be synthesized and that previously floated up into the prologue - but now it's pulled down past the prologue begin, so after the prologue this location-less zero is the first location.

I've reverted this patch (& dependent/follow-on patches) in 615f63e149f31d6a97b5233b4fe634db92e19aa9 <https://reviews.llvm.org/rG615f63e149f31d6a97b5233b4fe634db92e19aa9> - happy to help with further reproductions/validations (if/when you've got a proposed fix, if you can't run the gdb test suite or otherwise reproduce the failures, I can run our internal infrastructure to validate again)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D91734/new/

https://reviews.llvm.org/D91734