llvm / llvm/llvm-project

[DebugInfo][CorrelatedValuePropagation] Replacing `sext` with `zext` leaves a wrong debug value

Open
#218,623 1 comment 0 reactions 0 assignees View on GitHub
debuginfo llvm:transforms
Dominant language
LLVM
Stars
40.5k
Forks
18.7k
PR merge metrics
PR metrics pending

Description

## Description

`correlated-propagation` replaces a `sext` with `zext nneg` after proving that the extended value only affects program behavior when the input is non-negative. This preserves the program result, but the `#dbg_value` for the source variable `extended` remains attached to the zero-extended result.

For a negative input, sign extension and zero extension produce different values. Consequently, LLDB prints `extended` as `0x0000000080000000` after the pass instead of the source-level value `0xffffffff80000000`.

## Reproducer

`case.c`:

```c
long sext_to_zext(int x) {
long extended = x;
return x >= 0 ? extended : 24;
}

int main(void) { return sext_to_zext(-2147483647 - 1) != 24; }
```

Build pipeline:

```sh
clang -g -O0 -Xclang -disable-O0-optnone -fno-discard-value-names -S -emit-llvm case.c -o case.ll
opt -passes='mem2reg,simplifycfg' -S case.ll -o src.ll
opt -passes=correlated-propagation -S src.ll -o tgt.ll
clang src.ll -o src.out
clang tgt.ll -o tgt.out
```

Here are the complete [src.ll and tgt.ll](https://godbolt.org/z/n9M6G98e3).

`lldb-commands.txt`:

```text
breakpoint set --file case.c --line 3
run
frame variable --format hex extended
quit
```

Run LLDB on the binaries before and after `correlated-propagation`:

```sh
lldb src.out -s lldb-commands.txt
lldb tgt.out -s lldb-commands.txt
```

## Observed Behavior

Before `correlated-propagation`, LLDB reports the sign-extended value:

```text
== src.out ==
(long) extended = 0xffffffff80000000
```

After `correlated-propagation`, LLDB reports the zero-extended value:

```text
== tgt.out ==
(long) extended = 0x0000000080000000
```

The relevant IR before the pass is:

```llvm
%conv = sext i32 %x to i64, !dbg !17
#dbg_value(i64 %conv, !18, !DIExpression(), !16)
```

After the pass, `sext` has become `zext nneg`, but the debug record still describes `extended` directly with `%conv`:

```llvm
%conv = zext nneg i32 %x to i64, !dbg !17
#dbg_value(i64 %conv, !18, !DIExpression(), !16)
```

Here, `!18` is the source variable `extended`:

```llvm
!18 = !DILocalVariable(name: "extended", scope: !9, file: !1, line: 2, type: !12)
```

## Expected Behavior

The optimized debug information should not describe `extended` with the zero-extended result when it differs from the source-level sign extension. At the breakpoint on line 3, LLDB should either report the original value `0xffffffff80000000` (`-2147483648`) or report `extended` as unavailable if the source value cannot be represented after the transformation.

## Environment

```text
clang version 24.0.0git
llvm-project revision: f6ea145aa8e89631ae04f72df32580b20256d40c

LLVM version 24.0.0git
lldb version 24.0.0git
```

Contributor guide

Open the contributing guide

Research direction

Start with the case.c reproducer and the listed opt pipeline, comparing src.ll and tgt.ll around the sext-to-zext transformation and its #dbg_value record. Run the LLDB commands against both binaries to confirm the mismatch. Done means correlated-propagation no longer reports a zero-extended value for extended: LLDB should show the original sign-extended value or mark it unavailable.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
compilers, devtools
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.