Skip to content
  1. Feb 06, 2012
  2. Feb 05, 2012
  3. Feb 04, 2012
  4. Feb 03, 2012
  5. Feb 02, 2012
  6. Feb 01, 2012
    • Eric Christopher's avatar
      Remove duplicated comment. · 25a11e6d
      Eric Christopher authored
      llvm-svn: 149544
      25a11e6d
    • Eric Christopher's avatar
      Fix comment. · 034ba7e4
      Eric Christopher authored
      llvm-svn: 149543
      034ba7e4
    • Douglas Gregor's avatar
      Add missing dependency to unbreak the CMake build · c48190c1
      Douglas Gregor authored
      llvm-svn: 149531
      c48190c1
    • David Chisnall's avatar
      size() == 0 -> empty(). · af066bbb
      David Chisnall authored
      Spotted by rjmcall.
      
      llvm-svn: 149526
      af066bbb
    • Stepan Dyatkovskiy's avatar
      Compatability fix for SwitchInst refactoring. · 5fecf544
      Stepan Dyatkovskiy authored
      The purpose of refactoring is to hide operand roles from SwitchInst user (programmer). If you want to play with operands directly, probably you will need lower level methods than SwitchInst ones (TerminatorInst or may be User). After this patch we can reorganize SwitchInst operands and successors as we want.
      
      What was done:
      
      1. Changed semantics of index inside the getCaseValue method:
      getCaseValue(0) means "get first case", not a condition. Use getCondition() if you want to resolve the condition. I propose don't mix SwitchInst case indexing with low level indexing (TI successors indexing, User's operands indexing), since it may be dangerous.
      2. By the same reason findCaseValue(ConstantInt*) returns actual number of case value. 0 means first case, not default. If there is no case with given value, ErrorIndex will returned.
      3. Added getCaseSuccessor method. I propose to avoid usage of TerminatorInst::getSuccessor if you want to resolve case successor BB. Use getCaseSuccessor instead, since internal SwitchInst organization of operands/successors is hidden and may be changed in any moment.
      4. Added resolveSuccessorIndex and resolveCaseIndex. The main purpose of these methods is to see how case successors are really mapped in TerminatorInst.
      4.1 "resolveSuccessorIndex" was created if you need to level down from SwitchInst to TerminatorInst. It returns TerminatorInst's successor index for given case successor.
      4.2 "resolveCaseIndex" converts low level successors index to case index that curresponds to the given successor.
      
      Note: There are also related compatability fix patches for dragonegg, klee, llvm-gcc-4.0, llvm-gcc-4.2, safecode, clang.
      llvm-svn: 149482
      5fecf544
    • Argyrios Kyrtzidis's avatar
      Revert r149363 which was part a series of commits that were reverted in llvm · a11b35a9
      Argyrios Kyrtzidis authored
      commit 149470. This fixes test/CodeGen/PR3589-freestanding-libcalls.c.
      
      Original log:
      
          ConstantArray::get() (for strings) is going away, use
          ConstantDataArray::getString instead.
      
          Many instances of ConstantArray::get() could be moved to
          use more efficient ConstantDataArray methods that avoid a ton
          of intermediate Constant*'s for each element (e.g.
          GetConstantArrayFromStringLiteral).  I don't plan on doing this
          in the short-term though.
      
      llvm-svn: 149477
      a11b35a9
    • Eric Christopher's avatar
      For pass-by-value record arguments to functions emit a forward decl · ee4ab939
      Eric Christopher authored
      instead of the entire class definition.
      
      llvm-svn: 149474
      ee4ab939
  7. Jan 31, 2012
  8. Jan 30, 2012
  9. Jan 29, 2012
  10. Jan 28, 2012
  11. Jan 27, 2012
  12. Jan 26, 2012
    • Bob Wilson's avatar
      Make clz/ctz builtins defined for zero on ARM targets. rdar://10732455 · a7a61e27
      Bob Wilson authored
      ARM supports clz and ctz directly and both operations have well-defined
      results for zero.  There is no disadvantage in performance to using the
      defined-at-zero versions of llvm.ctlz/cttz intrinsics.  We're running into
      ARM-specific code written with the assumption that __builtin_clz(0) == 32,
      even though that value is technically undefined.  The code is failing now
      because of llvm optimizations that are taking advantage of the undef
      behavior (specifically svn r147255).  There's nothing wrong with that
      optimization on x86 where any incorrect assumptions about __builtin_clz(0)
      will quickly be exposed.  For ARM, though, optimizations based on that undef
      behavior are likely to cause subtle bugs.  Other targets with defined-at-zero
      clz/ctz support may want to override the default behavior as well.
      
      llvm-svn: 149086
      a7a61e27
    • Eric Christopher's avatar
      Use createRecordFwdDecl here since that's what we're doing. · f59218e5
      Eric Christopher authored
      llvm-svn: 149051
      f59218e5
    • Eric Christopher's avatar
      Revert previous patch unifying all of the C++ record prep in one area, · 8913bd6c
      Eric Christopher authored
      the gdb testsuite complains too much about the ordering of items printed,
      even if the offsets in the debug info are correct.
      
      This reverts commit 027cb30af828f07750f9185782822297a5c57231.
      
      llvm-svn: 149049
      8913bd6c
    • Eric Christopher's avatar
      Remove another duplicated variable. · 5720033c
      Eric Christopher authored
      llvm-svn: 149047
      5720033c
Loading