Repository: go
Issue: cmd/compile: regression in DWARF location lists caused by "issue VarDef only for pointer-ful types" 
Labels: NeedsInvestigation,compiler/runtime

### What version of Go are you using (`go version`)?

<pre>
go1.20. Also tip. Also go1.20-a74e5f584e.
</pre>

### Does this issue reproduce with the latest release?
Yes.


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/andrei/.cache/go-build"
GOENV="/home/andrei/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/andrei/work/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/andrei/work"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/andrei/sdk/go1.19.9"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/andrei/sdk/go1.19.9/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.19.9"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build802006892=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

There appears to have been a regression in the quality of debug information between 1.19 and 1.20. I have bisected it to 
a74e5f584 (`cmd/compile: issue VarDef only for pointer-ful types`), which is https://go-review.googlesource.com/c/go/+/419320.

It seems that this patch caused some local variables to no longer get their location lists emitted (i.e. the information telling debuggers the memory location of the variable in relation to different code locations).

Please consider the following program, which is the simplest repro I could produce:
https://go.dev/play/p/u9iYmn8GXVz
```go
package main

type T struct {
	// The size of the array matters; only 1 element is not enough for the demo.
	x [2]byte
	// Adding a pointer makes the problem go away, which seems to track with a74e5f584e.
	// p *int
}

//go:noinline
func foo() T {
	// t1 has a loclist before a74e5f584e
	var t1, t2 T
	_ = t2 // t2 is necessary for the demo; without it t1 is completely optimized out?
	return t1
}

func main() {
	foo()
}
```

Before a74e5f584e, the variable `t1` has the location information in debug info (pointing to the stack):

```
llvm-dwarfdump-16 --debug-info --color  --name=t1 --show-children <binary>
```

```
0x00015395: DW_TAG_variable
              DW_AT_name        ("t1")
              DW_AT_decl_line   (13)
              DW_AT_type        (0x0000000000001bf4 "main.T")
              DW_AT_location    (0x00000f61: 
                 [0x000000000045747c, 0x0000000000457490): DW_OP_fbreg -18)
```

After the patch though, it's no longer there:
```
0x00015395: DW_TAG_variable
              DW_AT_name        ("t1")
              DW_AT_decl_line   (13)
              DW_AT_type        (0x0000000000001bf4 "main.T")
              DW_AT_location    (<empty>)
```


Luckily, the generated machine code for `main.foo` is not changed by a74e5f584e as far as I can tell, so I am hoping that the code-generation benefits of that patch are not at odds with the quality of the debug info. 

The problem does not affect non-optimized builds (`-gcflags="all=-N").


### What did you expect to see?

I would like to have the location list for the `t1` variable.

### What did you see instead?

Location list is missing.

--- 

cc @randall77 @dr2chase  - the author and reviewer of a74e5f584e. 
Also kindly cc @aarzilli @thanm @neild - folks involved with https://go-review.googlesource.com/c/go/+/433479 which fixed other debug-info problems apparently caused by a74e5f584e.

I would like to timidly volunteer myself to work on a fix if that would be useful, provided that someone knowledgeable would enjoy holding my hand a bit and showing me the ropes in the relevant parts of the compiler. I would like to personally take a longer-term interest in Go's debug info.