and though bugs are the bane of my existence, rest assured the wretched thing will get the best of care here

  1. 30 Nov, 2012 2 commits
  2. 29 Nov, 2012 6 commits
  3. 28 Nov, 2012 4 commits
  4. 27 Nov, 2012 2 commits
  5. 26 Nov, 2012 5 commits
  6. 23 Nov, 2012 2 commits
  7. 22 Nov, 2012 4 commits
    • Pawel Wodnicki's avatar
      Merging r168291: into the 3.2 release branch. · 15386f41
      Pawel Wodnicki authored
      Fix PR14060, an infinite loop in reassociate.  The problem was that one of the
      operands of the expression being written was wrongly thought to be reusable as
      an inner node of the expression resulting in it turning up as both an inner node
      *and* a leaf, creating a cycle in the def-use graph.  This would have caused the
      verifier to blow up if things had gotten that far, however it managed to provoke
      an infinite loop first.
      
      llvm-svn: 168489
      15386f41
    • Pawel Wodnicki's avatar
      Merging r168355: into the 3.2 release branch. · 829dcd47
      Pawel Wodnicki authored
      Update method calls to the new interface re r168354.
      
      llvm-svn: 168487
      829dcd47
    • Pawel Wodnicki's avatar
      Merging r168354: into 3.2 release branch · 58b0a3b4
      Pawel Wodnicki authored
      Make the AttrListPtr object a part of the LLVMContext.
      
      When code deletes the context, the AttributeImpls that the AttrListPtr points to
      are now invalid. Therefore, instead of keeping a separate managed static for the
      AttrListPtrs that's reference counted, move it into the LLVMContext and delete
      it when deleting the AttributeImpls.
      
      llvm-svn: 168486
      58b0a3b4
    • Pawel Wodnicki's avatar
      Merging r168280: into 3.2 release branch. · 64b1fc8f
      Pawel Wodnicki authored
      Don't try to calculate the alignment of an unsigned type. Fixes PR14371!
      
      llvm-svn: 168480
      64b1fc8f
  8. 21 Nov, 2012 9 commits
    • Pawel Wodnicki's avatar
      Reverting 168457 · cda97b74
      Pawel Wodnicki authored
      llvm-svn: 168465
      cda97b74
    • Pawel Wodnicki's avatar
      Merging r168354, r168355 and r168379 into the 3.2 release branch. · 4570c1f2
      Pawel Wodnicki authored
      Set of  Attributes patches.
      
      Merging r168354:
      
      Make the AttrListPtr object a part of the LLVMContext.
      
      When code deletes the context, the AttributeImpls that the AttrListPtr points to
      are now invalid. Therefore, instead of keeping a separate managed static for the
      AttrListPtrs that's reference counted, move it into the LLVMContext and delete
      it when deleting the AttributeImpls.
      
      Merging r168355:
      
      Merging r168379
      
      llvm-svn: 168457
      4570c1f2
    • Pawel Wodnicki's avatar
      Merging r168181: into 3.2 release branch. · 29386c79
      Pawel Wodnicki authored
      Fix PR14361: wrong simplification of A+B==B+A.  You may think that the old logic
      replaced by this patch is equivalent to the new logic, but you'd be wrong, and
      that's exactly where the bug was.  There's a similar bug in instsimplify which
      manifests itself as instsimplify failing to simplify this, rather than doing it
      wrong, see next commit.
      
      llvm-svn: 168447
      29386c79
    • Pawel Wodnicki's avatar
      Merging r168035: into 3.2 release branch. · 467f9116
      Pawel Wodnicki authored
      Fix a crash observed by Shuxin Yang.  The issue here is that LinearizeExprTree,
      the utility for extracting a chain of operations from the IR, thought that it
      might as well combine any constants it came across (rather than just returning
      them along with everything else).  On the other hand, the factorization code
      would like to see the individual constants (this is quite reasonable: it is
      much easier to pull a factor of 3 out of 2*3 than it is to pull it out of 6;
      you may think 6/3 isn't so hard, but due to overflow it's not as easy to undo
      multiplications of constants as it may at first appear).  This patch therefore
      makes LinearizeExprTree stupider: it now leaves optimizing to the optimization
      part of reassociate, and sticks to just analysing the IR.
      
      llvm-svn: 168446
      467f9116
    • Pawel Wodnicki's avatar
      Merging r168361, r168346 and r168227 into 3.2 branch release · e3a27bc4
      Pawel Wodnicki authored
      Merging r168361: 
      
      Fix PR14132 and handle OOB loads speculated throuh PHI nodes.
      
      The issue is that we may end up with newly OOB loads when speculating
      a load into the predecessors of a PHI node, and this confuses the new
      integer splitting logic in some cases, triggering an assertion failure.
      In fact, the branch in question must be dead code as it loads from
      a too-narrow alloca. Add code to handle this gracefully and leave the
      requisite FIXMEs for both optimizing more aggressively and doing more to
      aid sanitizing invalid code which triggers these patterns.
      
      
      Merging r168346:
      ------------------------------------------------------------------------
      
      Rework the rewriting of loads and stores for vector and integer allocas
      to properly handle the combinations of these with split integer loads
      and stores. This essentially replaces Evan's r168227 by refactoring the
      code in a different way, and trynig to mirror that refactoring in both
      the load and store sides of the rewriting.
      
      Generally speaking there was some really problematic duplicated code
      here that led to poorly founded assumptions and then subtle bugs. Now
      much of the code actually flows through and follows a more consistent
      style and logical path. There is still a tiny bit of duplication on the
      store side of things, but it is much less bad.
      
      This also changes the logic to never re-use a load or store instruction
      as that was simply too error prone in practice.
      
      I've added a few tests (one a reduction of the one in Evan's original
      patch, which happened to be the same as the report in PR14349). I'm
      going to look at adding a few more tests for things I found and fixed in
      passing (such as the volatile tests in the vectorizable predicate).
      
      This patch has survived bootstrap, and modulo one bugfix survived
      Duncan's test suite, but let me know if anything else explodes.
      
      
      Merging r168227:
      
      Teach SROA rewriteVectorizedStoreInst to handle cases when the loaded value is narrower than the stored value. rdar://12713675
      
      llvm-svn: 168443
      e3a27bc4
    • Pawel Wodnicki's avatar
      Merging r168197: into 3.2 release branch · f18d5b46
      Pawel Wodnicki authored
      Preserve address space of forward-referenced global variables in the LL parser
      
      Before, the parser would assert on the following code:
      
      @a2 = global i8 addrspace(1)* @a
      @a = addrspace(1) global i8 0
      
      because the type of @a was "i8*" instead of "i8 addrspace(1)*" when parsing
      the initializer for @a2.
      
      llvm-svn: 168435
      f18d5b46
    • Pawel Wodnicki's avatar
      Merging r168319 into 3.2 release branch · c1b4549c
      Pawel Wodnicki authored
      Fix a pasto.
      
      llvm-svn: 168432
      c1b4549c
    • Pawel Wodnicki's avatar
      Merging r168063 into 3.2 release branch · 07081fe8
      Pawel Wodnicki authored
      block extended signatur option. Change previous option
      to a cc1 -fencode-extended-block-signature and pass it
      to cc1 and recognize this option to produce extended block
      type signature. // rdar://12109031 
      
      llvm-svn: 168419
      07081fe8
    • Pawel Wodnicki's avatar
      Merging r168297 into 3.2 release branch · 0d803938
      Pawel Wodnicki authored
      Completely re-work how the Clang driver interprets PIC and PIE options.
      
      There were numerous issues here that were all entangled, and so I've
      tried to do a general simplification of the logic.
      1) The logic was mimicing actual GCC bugs, rather than "features". These
         have been fixed in trunk GCC, and this fixes Clang as well. Notably,
         the logic was always intended to be last-match-wins like any other
         flag.
      2) The logic for handling '-mdynamic-no-pic' was preposterously unclear.
         It also allowed the use of this flag on non-Darwin platforms where it
         has no actual meaning. Now this option is handled directly based on
         tests of how llvm-gcc behaves, and it is only supported on Darwin.
      3) The APIs for the Driver's ToolChains had the implementation ugliness
         of dynamic-no-pic leaking through them. They also had the
         implementation details of the LLVM relocation model flag names
         leaking through.
      4) The actual results of passing these flags was incorrect on Darwin in
         many cases. For example, Darwin *always* uses PIC level 2 if it uses
         in PIC level, and Darwin *always* uses PIC on 64-bit regardless of
         the flags specified, including -fPIE. Darwin never compiles in PIE
         mode, but it can *link* in PIE mode.
      5) Also, PIC was not always being enabled even when PIE was. This isn't
         a supported mode at all and may have caused some fallout in builds
         with complex PIC and PIE interactions.
      
      The result is (I hope) cleaner and clearer for readers. I've also left
      comments and tests about some of the truly strage behavior that is
      observed on Darwin platforms. We have no real testing of Windows
      platforms and PIC, but I don't have the tools handy to figure that out.
      Hopefully others can beef up our testing here.
      
      Unfortunately, I can't test this for every platform. =/ If folks have
      dependencies on these flags that aren't covered by tests, they may
      break. I've audited and ensured that all the changes in behavior of the
      existing tests are intentional and good. In particular I've tried to
      make sure the Darwin behavior (which is more suprising than the Linux
      behavior) also matches that of 'gcc' on my mac.
      
      llvm-svn: 168416
      0d803938
  9. 20 Nov, 2012 6 commits