Missing variables after Instruction Selection at O2

[Quuxplusone]

Bugzilla Link	PR51780
Status	NEW
Importance	P enhancement
Reported by	Cristian Assaiante (cristianassaiante@outlook.com)
Reported on	2021-09-07 06:37:47 -0700
Last modified on	2021-10-05 08:07:18 -0700
Version	trunk
Hardware	PC Linux
CC	ditaliano@apple.com, jdevlieghere@apple.com, jeremy.morse.llvm@gmail.com, keith.walker@arm.com, llvm-bugs@lists.llvm.org, orlando.hyams@sony.com, paul_robinson@playstation.sony.com
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

Upon calling a function from an external module, the variable l_58 passed to it
is not visible from lldb. Using -opt-bisect-limit we discovered that the pass
causing the symbols disappear is "X86 DAG->DAG Instruction Selection on
function (main)"

$ cat a.c
short a;
void  b()
{
int l_41 = 0,  l_42 = 2,  l_50 = 1,  l_51 = 0,  l_55 = 1,  l_56 = 2,  l_57 = 1;
short l_58 = a ;
test_nop();
test_support_3032(l_41, l_42, l_50, l_51, l_55, l_56, l_57, l_58);
}
int main ()
{
b();
}

$ cat lib/test.c
#include <stdio.h>
#include <stdint.h>
#include "test.h"

void test_nop() {
    printf("\n");
}

void test_support_3032(int l_41, int l_42, int l_50, int l_51, int l_55, int
l_56, int l_57, int l_58) {
    printf("%d %d %d %d %d %d %d %d", l_41, l_42, l_50, l_51, l_55, l_56, l_57, l_58);
}

$ cat lib/test.h
#pragma once

void test_nop();

void test_support_3032(int l_41, int l_42, int l_50, int l_51, int l_55, int
l_56, int l_57, int l_58);

$ clang -v
clang version 13.0.0
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 -v
lldb version 13.0.0

clang revision c2c977ce50597b0e5186afc342c5784bd0aa6973
lldb revision c2c977ce50597b0e5186afc342c5784bd0aa6973

$ clang -g -O2 -o opt lib/test.c a.c
$ lldb opt
(lldb) target create "opt"
Current executable set to '/home/cristianrichie/91/reduce/opt' (x86_64).
(lldb) b 6
Breakpoint 1: 2 locations.
(lldb) r
Process 1990 launched: '/home/cristianrichie/91/reduce/opt' (x86_64)
Process 1990 stopped
* thread #1, name = 'opt', stop reason = breakpoint 1.2
    frame #0: 0x0000000000401188 opt`main [inlined] b at a.c:6:1
   3    {
   4    int l_41 = 0,  l_42 = 2,  l_50 = 1,  l_51 = 0,  l_55 = 1,  l_56 = 2,  l_57 = 1;
   5    short l_58 = a ;
-> 6    test_nop();
   7    test_support_3032(l_41, l_42, l_50, l_51, l_55, l_56, l_57, l_58);
   8    }
   9    int main ()
(lldb) frame var
(int) l_41 = 0
(int) l_42 = 2
(int) l_50 = 1
(int) l_51 = 0
(int) l_55 = 1
(int) l_56 = 2
(int) l_57 = 1
(lldb) frame var l_58
error: no variable named 'l_58' found in this frame

[Quuxplusone]

(Sifting through these tickets after a hiatus) -- my knee-jerk reaction here is that l_58 is going to decompose to a load-from-@a, that subsequently gets optimised out because nothing uses the value. I don't think we currently have a way to represent this in debug-info: we want to be able to refer to the value of @a when it was loaded at the start of the function, and that isn't affected by any subsequent stores to @a.