Patch for mem2reg pass

[David Blaikie]

On Wed, Jul 17, 2013 at 11:32 AM, Piotr Perek <pperek1234 at gmail.com> wrote:
> On 14.07.2013 20:31, David Blaikie wrote:
>>
>> Just for completeness you could check that the debug metadata
>> referenced by the dbg.value is the same metadata that defines the "i"
>> variable. (use a FileCheck capture (like this: [[I_VAR:![0-9]*]] ) to
>> capture the metadata number, then later on verify that that metadata
>> number has the debug info for the variable (something like [[I_VAR]] =
>> {{.*}} ; [ DW_TAG_auto_variable ] [i] or whatnot))
>
> I added test for checking if metadata referenced by dbg.value defines "i"
> variable.
>
>> Running this against my build I found a couple of problems, I've fixed
>> one in a naive way (checking that the map contains the element rather
>> than just accessing/default constructing it) - this failure came about
>> by running "make check-all" on my build tree (where I have compiler-rt
>> checked out, which is compiled by the fresh-built Clang, this tends to
>> exercise a lot of code paths that no one bothered to write regression
>> tests for). We (which is to say you, unless I find some more time to
>> prioritize this) should modify the existing test case (or add another
>> case to the same file, or another file if necessary) to exercise this
>> failure, rather than relying on the compiler-rt build to catch it.
>>
>> Also, the compiler-rt build is still failing with this change after my
>> first fix - seems to be some problems related to landing pads that I
>> haven't figured out yet.
>>
>> If you don't want/need to check out compiler-rt, you can probably
>> find/investigate/iron-out some of these issues by simply bootstrapping
>> LLVM (build LLVM with the just-built Clang). If you can't reproduce
>> the failures I've described with that (or resorting to checking out
>> compiler-rt), let me know & I can try to provide reproductions for you
>> to investigate & reduce.
>>
> I also checked out compiler-rt and made various tests. I compiled the LLVM
> using my modified LLVM, I performed tests both for LLVM and for Clang and
> compared test results for original and modified version, but I cannot
> reproduce the problem that you described. Could you give me more information
> about failures that you found. What is the structure of your LLVM build
> (what additional components you have added)? What tests allow reproducing
> this error?

Sorry for the lack of details - you should be able to reproduce the
bug that caused me to add the conditional fix (the "if this thing is
in the map then do stuff" bit that wasn't in your original patch) by
applying your original patch (without my fix) and having compiler-rt
checked out beneath llvm/projects then running "make check-all" or the
equivalent target for your build system. This will build LLVM and
Clang, then using the just-built Clang it'll build compiler-rt (this
is where you'll see the crash) and if that passes, it'll run the LLVM,
Clang, and Compiler-rt lit tests.

So what I'm hoping is you can reproduce the failure that lead to my
fix, reduce a test case so you can demonstrate that failure using the
llvm lit tests rather than using the compiler-rt build, then run the
same command (make check-all) again & hit the second issue that I
didn't get around to fixing yet, reduce a test case for that and fix
the issue... and if you're lucky, at that point you should be able to
get a "make check-all" to pass (unless there are other hidden issues
yet to be revealed).

At that point you might want to try a self-host. Build Clang, then
build Clang with that Clang.

>
> Best regards,
> Piotr