Variable not visible at Og

[Quuxplusone]

Bugzilla Link	PR47273
Status	CONFIRMED
Importance	P enhancement
Reported by	Luca Massarelli (massarelli@diag.uniroma1.it)
Reported on	2020-08-21 11:28:10 -0700
Last modified on	2020-08-24 14:50:56 -0700
Version	trunk
Hardware	PC Linux
CC	dblaikie@gmail.com, ditaliano@apple.com, jdevlieghere@apple.com, keith.walker@arm.com, llvm-bugs@lists.llvm.org, paul_robinson@playstation.sony.com, vsk@apple.com
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

Variable l_5 should be visible in all the scope of func_1. However, when
executing line 9 it is not visible anymore.

$ cat -n a.c
     1  int a;
     2  char b;
     3  char *c[2];
     4  void func_1() {
     5    int l_5 = 3, d = 0;
     6    for (; d < 2; d++)
     7      c[d] = b;
     8    for (;;) {
     9      if (l_5)
    10        break;
    11      a = &l_5;
    12      __assert_fail();
    13    }
    14  }
    15  int main() { func_1(); }

$ cat a.c
int a;
char b;
char *c[2];
void func_1() {
  int l_5 = 3, d = 0;
  for (; d < 2; d++)
    c[d] = b;
  for (;;) {
    if (l_5)
      break;
    a = &l_5;
    __assert_fail();
  }
}
int main() { func_1(); }

$ clang -v
clang version 12.0.0 (https://github.com/llvm/llvm-project.git
bc8be3054067ac822fc6d9f4f8e64c841f530f16)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Candidate multilib: .;@m64
Selected multilib: .;@m64

$ lldb opt
(lldb) target create "opt"
Current executable set to 'opt' (x86_64).
(lldb) b func_1
Breakpoint 1: where = opt`func_1 + 5 at a.c:5:7, address = 0x00000000004004e5
(lldb) r
Process 215 launched: 'opt' (x86_64)
Process 215 stopped
* thread #1, name = 'opt', stop reason = breakpoint 1.1
    frame #0: 0x00000000004004e5 opt`func_1 at a.c:5:7
   2    char b;
   3    char *c[2];
   4    void func_1() {
-> 5      int l_5 = 3, d = 0;
   6      for (; d < 2; d++)
   7        c[d] = b;
   8      for (;;) {
(lldb) s
Process 215 stopped
* thread #1, name = 'opt', stop reason = step in
    frame #0: 0x0000000000400500 opt`func_1 at a.c:7:10
   4    void func_1() {
   5      int l_5 = 3, d = 0;
   6      for (; d < 2; d++)
-> 7        c[d] = b;
   8      for (;;) {
   9        if (l_5)
   10         break;
(lldb) s
Process 215 stopped
* thread #1, name = 'opt', stop reason = step in
    frame #0: 0x0000000000400507 opt`func_1 at a.c:6:12
   3    char *c[2];
   4    void func_1() {
   5      int l_5 = 3, d = 0;
-> 6      for (; d < 2; d++)
   7        c[d] = b;
   8      for (;;) {
   9        if (l_5)
(lldb) s
Process 215 stopped
* thread #1, name = 'opt', stop reason = step in
    frame #0: 0x0000000000400500 opt`func_1 at a.c:7:10
   4    void func_1() {
   5      int l_5 = 3, d = 0;
   6      for (; d < 2; d++)
-> 7        c[d] = b;
   8      for (;;) {
   9        if (l_5)
   10         break;
(lldb) s
Process 215 stopped
* thread #1, name = 'opt', stop reason = step in
    frame #0: 0x0000000000400507 opt`func_1 at a.c:6:12
   3    char *c[2];
   4    void func_1() {
   5      int l_5 = 3, d = 0;
-> 6      for (; d < 2; d++)
   7        c[d] = b;
   8      for (;;) {
   9        if (l_5)
(lldb) p l_5
(int) $0 = 3
(lldb) s
Process 215 stopped
* thread #1, name = 'opt', stop reason = step in
    frame #0: 0x000000000040050d opt`func_1 at a.c:9:9
   6      for (; d < 2; d++)
   7        c[d] = b;
   8      for (;;) {
-> 9        if (l_5)
   10         break;
   11       a = &l_5;
   12       __assert_fail();
(lldb) p l_5
error: Couldn't materialize: couldn't get the value of variable l_5: variable
not available
error: errored out in DoExecute, couldn't PrepareToExecuteJITExpression

[Quuxplusone]

Remove the need of __assert_fail(), so it reproduces on macOS too:

davide@davides-ipro bin % cat a.c
int a;
char b;
char *c[2];
void func_1() {
  int l_5 = 3, d = 0;
  for (; d < 2; d++)
    c[d] = b;
  for (;;) {
    if (l_5)
      break;
    a = &l_5;
    assert();
  }
}
int main() { func_1(); }
davide@davides-ipro bin % cat b.c
void assert() {}

[Quuxplusone]

Confirmed. The range of l_3 is too short and can't be seen inside the loop.

[Quuxplusone]

The IR looks fine:

17:                                               ; preds = %9, %17
  store i32 %11, i32* @a, align 4, !dbg !55, !tbaa !30
  %18 = call i32 (...) @assert() #4, !dbg !56
  %19 = load i32, i32* %1, align 4, !dbg !39, !tbaa !30
  call void @llvm.dbg.value(metadata i32 %19, metadata !25, metadata !DIExpression()), !dbg !28
  %20 = icmp eq i32 %19, 0, !dbg !39
  br i1 %20, label %17, label %21, !dbg !44, !llvm.loop !57

[...]

!25 = !DILocalVariable(name: "l_5", scope: !21, file: !3, line: 5, type: !8)

[Quuxplusone]

The DWARF produced seems to know:

0x000000a8:     DW_TAG_variable
                  DW_AT_location        (0x00000000:
                     [0x0000000100003f36, 0x0000000100003f5e): DW_OP_consts +3, DW_OP_stack_value)
                  DW_AT_name    ("l_5")
                  DW_AT_decl_file       ("/Users/davide/work/build/bin/a.c")
                  DW_AT_decl_line       (5)
                  DW_AT_type    (0x00000043 "int")

[Quuxplusone]

Interestingly enough, the range is open:

Process 78764 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step over
    frame #0: 0x0000000100003f5e a`func_1 at a.c:9:9 [opt]
   6      for (; d < 2; d++)
   7        c[d] = b;
   8      for (;;) {
-> 9        if (l_5)
   10         break;
   11       a = &l_5;
   12       assert();

so we really miss this for a byte.

(lldb) dis
a`func_1:
    0x100003f30 <+0>:  pushq  %rbp
    0x100003f31 <+1>:  movq   %rsp, %rbp
    0x100003f34 <+4>:  pushq  %rbx
    0x100003f35 <+5>:  pushq  %rax
    0x100003f36 <+6>:  movl   $0x3, -0xc(%rbp)
    0x100003f3d <+13>: movsbq 0xbb(%rip), %rax          ; b
    0x100003f45 <+21>: xorl   %ecx, %ecx
    0x100003f47 <+23>: leaq   0xc2(%rip), %rdx          ; c
    0x100003f4e <+30>: nop
    0x100003f50 <+32>: movq   %rax, (%rcx,%rdx)
    0x100003f54 <+36>: addq   $0x8, %rcx
    0x100003f58 <+40>: cmpq   $0x8, %rcx
    0x100003f5c <+44>: je     0x100003f50               ; <+32> at a.c:7:10
->  0x100003f5e <+46>: cmpl   $0x0, -0xc(%rbp)

[Quuxplusone]

Looks like ISel has already the problem:

# *** IR Dump After X86 DAG->DAG Instruction Selection ***:
# Machine code for function func_1: IsSSA, TracksLiveness
Frame Objects:
  fi#0: size=4, align=4, at location [SP+8]
bb.0 (%ir-block.0):
  successors: %bb.3(0x80000000); %bb.3(100.00%)
  LIFETIME_START %stack.0, debug-location !27; a.c:5:3
  DBG_VALUE 3, $noreg, !"l_5", !DIExpression(), debug-location !28; a.c:0 line no:5
  MOV32mi %stack.0, 1, $noreg, 0, $noreg, 3, debug-location !29 :: (store 4 into %ir.1, !tbaa !30); a.c:5:7
  DBG_VALUE 0, $noreg, !"d", !DIExpression(), debug-location !28; a.c:0 line no:5
  %0:gr64 = MOVSX64rm8 $rip, 1, $noreg, @b, $noreg, debug-location !34 :: (dereferenceable load 1 from @b, !tbaa !37); a.c:0
  %5:gr32 = MOV32r0 implicit-def dead $eflags
  %4:gr64 = SUBREG_TO_REG 0, killed %5:gr32, %subreg.sub_32bit
  JMP_1 %bb.3, debug-location !38; a.c:6:3
bb.1 (%ir-block.5):
; predecessors: %bb.3
  successors: %bb.2(0x30000000), %bb.5(0x50000000); %bb.2(37.50%), %bb.5(62.50%)
  DBG_VALUE $noreg, $noreg, !"l_5", !DIExpression(), debug-location !28; a.c:0 line no:5
  CMP32mi8 %stack.0, 1, $noreg, 0, $noreg, 0, implicit-def $eflags, debug-location !39 :: (dereferenceable load 4 from %ir.1, !tbaa !30); a.c:9:9
  JCC_1 %bb.5, 5, implicit $eflags, debug-location !44; a.c:9:9
  JMP_1 %bb.2, debug-location !44; a.c:9:9