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

[David Blaikie via llvm-dev]

On Fri, Oct 7, 2016 at 2:20 PM Xinliang David Li <davidxl at google.com> wrote:

> On Fri, Oct 7, 2016 at 1:35 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>
>
> 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.
>
>
> I agree with you that this is a good/intended goal, but it is not
> 'abstract' good goal :)
>

Abstract in the sense that no one's had concrete needs for/problems with it
so far - or insufficiently so that it wasn't worth working on.


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