|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| | 
| 
| 
| | llvm-svn: 275304 | 
| | 
| 
| 
| 
| 
| 
| 
| | Patch by Sunita Marathe
Differential Revision: http://reviews.llvm.org/D21920
llvm-svn: 275284 | 
| | 
| 
| 
| 
| 
| 
| | Chandler pointed out in his review but I forgot to remove before
committing, my bad.
llvm-svn: 274963 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | While here move simplifyLoop() function to the new header, as
suggested by Chandler in the review.
Differential Revision:  http://reviews.llvm.org/D21404
llvm-svn: 274959 | 
| | 
| 
| 
| | llvm-svn: 274927 | 
| | 
| 
| 
| | llvm-svn: 274796 | 
| | 
| 
| 
| 
| 
| | moved the optimise for size check inside function optimizeFPuts.
llvm-svn: 274758 | 
| | 
| 
| 
| 
| 
| | because fwrite requires more arguments and thus extra MOVs are required.
llvm-svn: 274753 | 
| | 
| 
| 
| 
| 
| | Differential Revision: http://reviews.llvm.org/D22058
llvm-svn: 274679 | 
| | 
| 
| 
| 
| 
| | MemorySSA construction
llvm-svn: 274606 | 
| | 
| 
| 
| | llvm-svn: 274590 | 
| | 
| 
| 
| 
| 
| | Differential Revision: http://reviews.llvm.org/D21636
llvm-svn: 274334 | 
| | 
| 
| 
| | llvm-svn: 273974 | 
| | 
| 
| 
| 
| 
| | NFC.
llvm-svn: 273901 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | build.
There's a known bug in msvc 2013 that fails to compile do-while loops
inside of ranged for loops.
llvm-svn: 273811 | 
| | 
| 
| 
| 
| 
| | Only minor manual fixes. No functionality change intended.
llvm-svn: 273808 | 
| | 
| 
| 
| 
| 
| | No functional change is intended
llvm-svn: 273780 | 
| | 
| 
| 
| 
| 
| | This reverts commit r273778, it seems to break UBSan :/
llvm-svn: 273779 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | SimplifyCFG had logic to insert calls to llvm.trap for two very
particular IR patterns: stores and invokes of undef/null.
While InstCombine canonicalizes certain undefined behavior IR patterns
to stores of undef, phase ordering means that this cannot be relied upon
in general.
There are much better tools than llvm.trap: UBSan and ASan.
N.B. I could be argued into reverting this change if a clear argument as
to why it is important that we synthesize llvm.trap for stores, I'd be
hard pressed to see why it'd be useful for invokes...
llvm-svn: 273778 | 
| | 
| 
| 
| 
| 
| 
| | Calling null is undefined behavior, a call to undef can be trivially
treated as a call to null.
llvm-svn: 273776 | 
| | 
| 
| 
| | llvm-svn: 273761 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | r273711 was reverted by r273743.  The inliner needs to know about any
call sites in the inlined function.  These were obscured if we replaced
a call to undef with an undef but kept the call around.
This fixes PR28298.
llvm-svn: 273753 | 
| | 
| 
| 
| | llvm-svn: 273752 | 
| | 
| 
| 
| | llvm-svn: 273743 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This patch moves MSSA's caching walker into MemorySSA, and moves the
actual definition of MSSA's caching walker out of MemorySSA.h. This is
done in preparation for the new walker, which should be out for review
soonish.
Also, this patch removes a field from UpwardsMemoryQuery and has a few
lines of diff from clang-format'ing MemorySSA.cpp.
llvm-svn: 273723 | 
| | 
| 
| 
| 
| 
| 
| | We cannot remove an instruction with no uses just because
SimplifyInstruction succeeds.  It may have side effects.
llvm-svn: 273711 | 
| | 
| 
| 
| 
| 
| 
| | This makes the code a little more concise, no functional change is
intended.
llvm-svn: 273644 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | reduce the number of comparisons.
Specifically, InstCombine can turn:
  (i == 5334 || i == 5335)
into:
  ((i | 1) == 5335)
SimplifyCFG was already able to detect the pattern:
  (i == 5334 || i == 5335)
to:
  ((i & -2) == 5334)
This patch supersedes D21315 and resolves PR27555
(https://llvm.org/bugs/show_bug.cgi?id=27555).
Thanks to David and Chandler for the suggestions!
Author: Thomas Jablin (tjablin)
Reviewers: majnemer chandlerc halfdan cycheng
http://reviews.llvm.org/D21397
llvm-svn: 273639 | 
| | 
| 
| 
| 
| 
| | Found by gcc 6.
llvm-svn: 273402 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | Reviewers: george.burgess.iv, gberry, hfinkel
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D21463
llvm-svn: 273295 | 
| | 
| 
| 
| | llvm-svn: 273194 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | CodeGen has hooks that allow targets to emit specialized code instead
of calls to memcmp, memchr, strcpy, stpcpy, strcmp, strlen, strnlen.
When ASan/MSan/TSan/ESan is in use, this sidesteps its interceptors, resulting
in uninstrumented memory accesses.  To avoid that, make these sanitizers
mark the calls as nobuiltin.
Differential Revision: http://reviews.llvm.org/D19781
llvm-svn: 273083 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Switch from m_Constant to m_APInt per David's request. NFC.
Author: Thomas Jablin (tjablin)
Reviewers: majnemer cycheng
http://reviews.llvm.org/D21440
llvm-svn: 272977 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | When moving unsafe allocas to the unsafe stack, dbg.declare intrinsics are
updated to refer to the new location.
This change does the same to dbg.value intrinsics.
llvm-svn: 272968 | 
| | 
| 
| 
| 
| 
| 
| 
| | BranchProbabilityInfo"
It was causing failures in Profile-i386 and Profile-x86_64 tests.
llvm-svn: 272912 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | We should update results of the BranchProbabilityInfo after removing block in JumpThreading. Otherwise 
we will get dangling pointer inside BranchProbabilityInfo cache.
Differential Revision: http://reviews.llvm.org/D20957
llvm-svn: 272891 | 
| | 
| 
| 
| 
| 
| 
| | Soon we won't be passing Strides to getInfo and then we'll have fewer
call sites to update.
llvm-svn: 272878 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | (i == 5334 || i == 5335)
to:
    ((i & -2) == 5334)
This transformation has some incorrect side conditions. Specifically, the
transformation is only applied when the right-hand side constant (5334 in
the example) is a power of two not equal and not equal to the negated mask.
These side conditions were added in r258904 to fix PR26323. The correct side
condition is that: ((Constant & Mask) == Constant)[(5334 & -2) == 5334].
It's a little bit hard to see why these transformations are correct and what
the side conditions ought to be. Here is a CVC3 program to verify them for
64-bit values:
    ONE  : BITVECTOR(64) = BVZEROEXTEND(0bin1, 63);
    x    : BITVECTOR(64);
    y    : BITVECTOR(64);
    z    : BITVECTOR(64);
    mask : BITVECTOR(64) = BVSHL(ONE, z);
    QUERY( (y & ~mask = y) =>
           ((x & ~mask = y) <=> (x = y OR x = (y |  mask)))
    );
Please note that each pattern must be a dual implication (<--> or iff). One
directional implication can create spurious matches. If the implication is
only one-way, an unsatisfiable condition on the left side can imply a
satisfiable condition on the right side. Dual implication ensures that
satisfiable conditions are transformed to other satisfiable conditions and
unsatisfiable conditions are transformed to other unsatisfiable conditions.
Here is a concrete example of a unsatisfiable condition on the left
implying a satisfiable condition on the right:
    mask = (1 << z)
    (x & ~mask) == y --> (x == y || x == (y | mask))
Substituting y = 3, z = 0 yields:
    (x & -2) == 3 --> (x == 3 || x == 2)
The version of this code before r258904 had no side-conditions and
incorrectly justified itself in comments through one-directional
implication.
Thanks to Chandler for the suggestion!
Author: Thomas Jablin (tjablin)
Reviewers: chandlerc majnemer hfinkel cycheng
http://reviews.llvm.org/D21417
llvm-svn: 272873 | 
| | 
| 
| 
| | llvm-svn: 272850 | 
| | 
| 
| 
| | llvm-svn: 272847 | 
| | 
| 
| 
| 
| 
| | In preparation for porting this pass to the new PM.
llvm-svn: 272818 | 
| | 
| 
| 
| 
| 
| 
| 
| | Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D21344
llvm-svn: 272712 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | If a local_unnamed_addr attribute is attached to a global, the address
is known to be insignificant within the module. It is distinct from the
existing unnamed_addr attribute in that it only describes a local property
of the module rather than a global property of the symbol.
This attribute is intended to be used by the code generator and LTO to allow
the linker to decide whether the global needs to be in the symbol table. It is
possible to exclude a global from the symbol table if three things are true:
- This attribute is present on every instance of the global (which means that
  the normal rule that the global must have a unique address can be broken without
  being observable by the program by performing comparisons against the global's
  address)
- The global has linkonce_odr linkage (which means that each linkage unit must have
  its own copy of the global if it requires one, and the copy in each linkage unit
  must be the same)
- It is a constant or a function (which means that the program cannot observe that
  the unique-address rule has been broken by writing to the global)
Although this attribute could in principle be computed from the module
contents, LTO clients (i.e. linkers) will normally need to be able to compute
this property as part of symbol resolution, and it would be inefficient to
materialize every module just to compute it.
See:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html
for earlier discussion.
Part of the fix for PR27553.
Differential Revision: http://reviews.llvm.org/D20348
llvm-svn: 272709 | 
| | 
| 
| 
| 
| 
| 
| 
| | Ensuring that the PHI are all single-operand is not performed in the
second pass added by the previous pass.  This removes the assert from
the first pass.
llvm-svn: 272650 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | We only used to add the edge from the cloned loop to PHIs that
corresponded to values defined by the loop.  We need to do this for all
PHIs obviously since we need a PHI operand for each incoming edge.
This includes things like PHIs with a constant value or with values
defined before the original loop (see the testcases).
After the patch the PHIs are added to the exit block in two passes.
In the first pass we ensure there is a single-operand (LCSSA) PHI for
each value defined by the loop.
In the second pass we loop through each (single-operand) PHI and add the
value for the edge from the cloned loop.  If the value is defined in the
loop we'll use the cloned instruction from the cloned loop.
Fixes PR28037
llvm-svn: 272649 | 
| | 
| 
| 
| | llvm-svn: 272630 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | Reviewers: ashutosh.nema
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D21281
llvm-svn: 272545 | 
| | 
| 
| 
| 
| 
| | No functionality change intended.
llvm-svn: 272516 | 
| | 
| 
| 
| 
| 
| | Or replace with llvm::function_ref if it's never stored. NFC intended.
llvm-svn: 272513 | 
| | 
| 
| 
| 
| 
| 
| 
| | This used to be free, copying and moving DebugLocs became expensive
after the metadata rewrite. Passing by reference eliminates a ton of
track/untrack operations. No functionality change intended.
llvm-svn: 272512 |