|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| ... |  | 
| | 
| 
| 
| | llvm-svn: 160621 | 
| | 
| 
| 
| 
| 
| | moved earlier. This fixes some layering issues.
llvm-svn: 160611 | 
| | 
| 
| 
| | llvm-svn: 160603 | 
| | 
| 
| 
| 
| 
| 
| 
| | r160529 that was subsequently reverted. The fix was to not call
GV->eraseFromParent() right before the caller does the same. The existing
testcases already caught this bug if run under valgrind.
llvm-svn: 160602 | 
| | 
| 
| 
| 
| 
| 
| 
| | belongs. I dunno why in the world I dropped it in the Scalar folder in the first place.
No functionality change.
llvm-svn: 160587 | 
| | 
| 
| 
| 
| 
| 
| 
| | GetBestDestForJumpOnUndef() assumes there is at least 1 successor, which isn't
true if the block ends in an indirect branch with no successors. Fix this by
bailing out earlier in this case.
llvm-svn: 160546 | 
| | 
| 
| 
| 
| 
| | idea: insert an empty InlineAsm). Change the order in which the new BBs are inserted: the slow path BB is insert between old BBs, the crash BB is inserted at the end. Don't create an empty BB (introduced by recent commits). Update the test. The experimental code that does manual crash callback merge will most likely be deleted later.
llvm-svn: 160544 | 
| | 
| 
| 
| | llvm-svn: 160532 | 
| | 
| 
| 
| 
| 
| | memory. This makes clang play nice with leak checkers.
llvm-svn: 160529 | 
| | 
| 
| 
| 
| 
| | No functionality change.
llvm-svn: 160501 | 
| | 
| 
| 
| | llvm-svn: 160477 | 
| | 
| 
| 
| 
| 
| | Minor oversight noticed by inspection. Sorry no unit test.
llvm-svn: 160422 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Fixes PR13371: indvars pass incorrectly substitutes 'undef' values.
I do not like this fix. It's needed until/unless the meaning of undef
changes. It attempts to be complete according to the IR spec, but I
don't have much confidence in the implementation given the difficulty
testing undefined behavior. Worse, this invalidates some of my
hard-fought work on indvars and LSR to optimize pointer induction
variables. It results benchmark regressions, which I'll track
internally. On x86_64 no LTO I see:
-3% huffbench
-3% 400.perlbench
-8% fhourstones
My only suggestion for recovering is to change the meaning of
undef. If we could trust an arbitrary instruction to produce a some
real value that can be manipulated (e.g. incremented) according to
non-undef rules, then this case could be easily handled with SCEV.
llvm-svn: 160421 | 
| | 
| 
| 
| 
| 
| | instcombine transformation.
llvm-svn: 160387 | 
| | 
| 
| 
| 
| 
| | allows to hold performance experiments
llvm-svn: 160361 | 
| | 
| 
| 
| 
| 
| | Speculatively fix crashes by code inspection. Can't reproduce them yet.
llvm-svn: 160344 | 
| | 
| 
| 
| 
| 
| | Some units tests crashed on a different platform.
llvm-svn: 160341 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | This places limits on CollectSubexprs to constrains the number of
reassociation possibilities. It limits the recursion depth and skips
over chains of nested recurrences outside the current loop.
Fixes PR13361. Although underlying SCEV behavior is still potentially bad.
llvm-svn: 160340 | 
| | 
| 
| 
| | llvm-svn: 160325 | 
| | 
| 
| 
| 
| 
| | chandlerc, partially implemented crash callback merging (under flag)
llvm-svn: 160290 | 
| | 
| 
| 
| 
| 
| | fully implemented yet, no functionality change except the BB order)
llvm-svn: 160284 | 
| | 
| 
| 
| 
| 
| | on-demand
llvm-svn: 160269 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | It turns out that ASan relied on the at-the-end block insertion order to
(purely by happenstance) disable some LLVM optimizations, which in turn
start firing when the ordering is made more "normal". These
optimizations in turn merge many of the instrumentation reporting calls
which breaks the return address based error reporting in ASan.
We're looking at several different options for fixing this.
llvm-svn: 160256 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | This is particularly useful to the backend code generators which try to
process things in the incoming function order.
Also, cleanup some uses of IRBuilder to be a bit simpler and more clear.
llvm-svn: 160254 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | the move of *Builder classes into the Core library.
No uses of this builder in Clang or DragonEgg I could find.
If there is a desire to have an IR-building-support library that
contains all of these builders, that can be easily added, but currently
it seems likely that these add no real overhead to VMCore.
llvm-svn: 160243 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | IRBuilder, DIBuilder, etc.
This is the proper layering as MDBuilder can't be used (or implemented)
without the Core Metadata representation.
Patches to Clang and Dragonegg coming up.
llvm-svn: 160237 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | All SCEV expressions used by LSR formulae must be safe to
expand. i.e. they may not contain UDiv unless we can prove nonzero
denominator.
Fixes PR11356: LSR hoists UDiv.
llvm-svn: 160205 | 
| | 
| 
| 
| | llvm-svn: 160173 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | %shr = lshr i64 %key, 3
  %0 = load i64* %val, align 8
  %sub = add i64 %0, -1
  %and = and i64 %sub, %shr
  ret i64 %and
to:
  %shr = lshr i64 %key, 3
  %0 = load i64* %val, align 8
  %sub = add i64 %0, 2305843009213693951
  %and = and i64 %sub, %shr
  ret i64 %and
The demanded bit optimization is actually a pessimization because add -1 would
be codegen'ed as a sub 1. Teach the demanded constant shrinking optimization
to check for negated constant to make sure it is actually reducing the width
of the constant.
rdar://11793464
llvm-svn: 160101 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | mallocs/callocs/...
This patch removes ~70 lines in InstCombineLoadStoreAlloca.cpp and makes both functions a bit more aggressive than before :)
In theory, we can be more aggressive when removing an alloca than a malloc, because an alloca pointer should never escape, but we are not taking advantage of this anyway
llvm-svn: 159952 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | memcpy/memmove/memset, and objectsize users.
This means we can do cheap DSE for heap memory.
Nothing is done if the pointer excapes or has a load.
The churn in the tests is mostly due to objectsize, since we want to make sure we
don't delete the malloc call before evaluating the objectsize (otherwise it becomes -1/0)
llvm-svn: 159876 | 
| | 
| 
| 
| 
| 
| | (tsan issue #3). A unit test will follow separately.
llvm-svn: 159736 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | be used here:
  IntegersSubsetMapping
  - Replaced type of Items field from std::list with std::map. In neares future I'll test it with DenseMap and do the correspond replacement
    if possible.
llvm-svn: 159703 | 
| | 
| 
| 
| 
| 
| 
| 
| | be >= 0 (signed).
(LLVM optimizers cannot do this optimization by themselves)
llvm-svn: 159668 | 
| | 
| 
| 
| 
| 
| 
| 
| | IntegersSubsetMapping
  - Replaced type of Items field from std::list with std::map. In neares future I'll test it with DenseMap and do the correspond replacement
    if possible.
llvm-svn: 159659 | 
| | 
| 
| 
| 
| 
| | This reverts commit b2833d9dcba88c6f0520cad760619200adc0442c.
llvm-svn: 159618 | 
| | 
| 
| 
| | llvm-svn: 159546 | 
| | 
| 
| 
| 
| 
| | nodes in unwind BB
llvm-svn: 159534 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | - Changed isSingleNumber method behaviour. Now this flag is calculated on demand.
IntegersSubsetMapping
  - Optimized diff operation.
  - Replaced type of Items field from std::list with std::map.
  - Added new methods:
    bool isOverlapped(self &RHS)
    void add(self& RHS, SuccessorClass *S)
    void detachCase(self& NewMapping, SuccessorClass *Succ)
    void removeCase(SuccessorClass *Succ)
    SuccessorClass *findSuccessor(const IntTy& Val)
    const IntTy* getCaseSingleNumber(SuccessorClass *Succ)
IntegersSubsetTest
  - DiffTest: Added checks for successors.
SimplifyCFG
  Updated SwitchInst usage (now it is case-ragnes compatible) for
    - SimplifyEqualityComparisonWithOnlyPredecessor
    - FoldValueComparisonIntoPredecessors
llvm-svn: 159527 | 
| | 
| 
| 
| | llvm-svn: 159522 | 
| | 
| 
| 
| | llvm-svn: 159491 | 
| | 
| 
| 
| 
| 
| | this point
llvm-svn: 159471 | 
| | 
| 
| 
| 
| 
| | This happens when codegenprepare is invoked via opt.
llvm-svn: 159457 | 
| | 
| 
| 
| 
| 
| | really happening.  No intended functionality change.
llvm-svn: 159451 | 
| | 
| 
| 
| 
| 
| | not ready to handle invokes. instcombine will take care of this.
llvm-svn: 159440 | 
| | 
| 
| 
| 
| 
| 
| | the optimizers producing a multiply expression with more multiplications than
the original (!).
llvm-svn: 159426 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This was always part of the VMCore library out of necessity -- it deals
entirely in the IR. The .cpp file in fact was already part of the VMCore
library. This is just a mechanical move.
I've tried to go through and re-apply the coding standard's preferred
header sort, but at 40-ish files, I may have gotten some wrong. Please
let me know if so.
I'll be committing the corresponding updates to Clang and Polly, and
Duncan has DragonEgg.
Thanks to Bill and Eric for giving the green light for this bit of cleanup.
llvm-svn: 159421 | 
| | 
| 
| 
| 
| 
| 
| | (a.k.a. MDNodes). The module doesn't belong in Analysis. Move it to the VMCore
instead.
llvm-svn: 159414 | 
| | 
| 
| 
| | llvm-svn: 159385 | 
| | 
| 
| 
| | llvm-svn: 159384 |