[LLVMbugs] [Bug 16594] New: Dynamic Alloca Miscompile of AnalysisConsumer.cpp.

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=16594

            Bug ID: 16594
           Summary: Dynamic Alloca Miscompile of AnalysisConsumer.cpp.
           Product: libraries
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: mgottesman at apple.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10861
  --> http://llvm.org/bugs/attachment.cgi?id=10861&action=edit
Patch including instrumentation and my version of Nick's original patch.

=======
Summary
=======

Recently I picked up a patch which enhances the TRE pass to handle captured
allocas more intelligently. My patch was based off of a patch originally by
Nick Lewycky that did not make it into the tree due to it causing miscompiles
in clang itself during a bootstrap build. My version of the patch does not
cause this miscompile since it is more conservative.

In order to be safe, I spent some time narrowing down the miscompile, but have
since run out of time to look at the problem. Thus Nick and I agreed that I
could commit my version of the patch (since it avoids the miscompile) and file
a PR for the bug. This is said PR.

Relevant threads:

Original patch:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121022/153958.html

David Sehr's Thread:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130204/165122.html

===========
Reproducing
=========== 

Attached is a patch which instruments selectiondag/tre with counters. To
reproduce the bug, perform a release/asserts bootstrap build of clang without
the counters set and then attempt to run the tests. You should get 3x assertion
failures.

*NOTE* If you perform a straight release build without asserts you will get
many more failures. I decided to debug the asserts build with the idea that
perhaps if I was lucky (which I was), I would get an assert failure that would
be easier to debug since I would know earlier during the static analysis when
the failure occurred. I was lucky in this case.

I was able to bisect the problem .o down to AnalysisConsumer.o by
mixing/matching stage 1/stage 2 object files. Once I did that, I noticed that
if I recompiled AnalysisConsumer.o with fastisel and relinked the stage2, the
test failure went away. This caused me to conclude that the bug is in selection
dag. Then I was able to use the counter that I placed in selectiondag to
isolate the basic block in AnalysisConsumer.o that caused the issue. The
counter works by causing fastisel to only run when the basic block counter
equals a specific value. The value that works is 3875.

*NOTE* I found this value by originally bisecting said counter and bailing once
a specific counter value was reached. Then I changed the counter so it would
only cause fast isel on one BB and selectiondag on all the others hoping that
the problem was in one BB. My hopes were well founded = ).

The specific function/BB we are interested in is:

Function:
_ZN5clang19RecursiveASTVisitorIN12_GLOBAL__N_116AnalysisConsumerEE15TraverseTypeLocENS_7TypeLocE
MachineFunctionBB: BB#23
Assembly Label: LBB120_21

When I showed it to Jakob, his opinion was that both the good/bad basic blocks
look bogus, but the good one is more correct. Specifically, we should be
creating stack slots for 8 dynamic allocas. Instead we are moving the same
value into most of those registers. His suspicion that the reason the fast-isel
version is more correct (but still incorrect in the sense that a different test
case may get the wrong result) is that fast isel is processing a part of the
block, seeing the dynamic alloca and then bailing to selectiondag.

===========
Attachments
===========

1. The patch itself.
2. The IR.
3. The bad assembly (i.e. all selection dag).
4. The good assembly (i.e. all selection dag except 1 basic block).
5. Bad machine instr print out.
6. Good machine instr print out.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130711/60f58443/attachment.html>