[llvm-dev] Debug info interacting with optimization and code generation

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Fri Oct 7 13:35:38 PDT 2016


On Fri, Oct 7, 2016 at 1:27 PM Dehao Chen <dehao at google.com> wrote:

> In theory, compiler should generate bit-identical code with and without
> debug info. I.e.
> # clang -c -O2 -g a.cc -o a.g.o
> # clang -c -O2 -g0 a.cc -o a.g0.o
> # strip a.g.o a.g0.o
> # diff a.g.o a.g0.o
> The diff should find two binaries identical. For brevity, in the rest of
> the mail, I'll refer to this requirement as "codegen consistency" (any
> better name?)
>
> Unfortunately, LLVM does not guarantee codegen consistency. Recently, I've
> spent quite some time try to fix related issues (e.g.
> https://reviews.llvm.org/D25286 and https://reviews.llvm.org/D25098). The
> most recent issue I'm looking at is that during isel, the IROrder is used
> by both debug info and the actual codegen, which is relative harder to fix.
>
> I initially thought that it's just a couple of careless bugs to fix. But
> looks like there are much more issues than I expected. So I'm calling the
> community for help:
>
> * Is there anyone else who also cares about codegen consistency?
> * Any volunteers to help fix codegen consistency issues? (It is easy to
> find issues, just build speccpu with -g and -g0, then compare the "objdump
> -d" output)
> * How to setup a regression test to ensure future changes does not break
> codegen consistency?
>

Specific test cases would be checked in as usual - beyond that, probably a
self-host that checks for consistency (like a 3 stage bootstrap checks that
stage 2 and 3 are identical). Potentially other workloads could be added if
a selfhost didn't offer enough certainty for common cases.

It's an abstract good/intended goal, for sure - but it's not been a
priority for anyone (as you've seen), so just hasn't been pushed very
hard/far.

- Dave


>
> Any comments?
>
> Thanks,
> Dehao
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161007/e538f05b/attachment.html>


More information about the llvm-dev mailing list