It wasn't very obvious that you're supposed to call help on the
subcommands. This should help.

llvm-svn: 277678

Patch by Bittner Barni!

Differential revision: https://reviews.llvm.org/D20196

llvm-svn: 277677

1. Improve templated class renaming, namely add capabilities of finding partial
and full specializations. Every class partial specialization has reference to
the specialized class. Thus, storing all partial specializations and
comparing specialized class decls to the FoundDecl solves this. All full class
specializations can be found by calling ClassTemplateDecl::specializations().

2. Fix virtual function and its overriding functions renaming. Renaming a
virtual function requires renaming every other function in its "overriding
graph".

3. Merge TemplateClassInstantiationFindBy{Declaration|TypeUse}.cpp tests into
one test by adding multiple invocations of clang-rename to one test, because
the only different thing across these tests is -offset passed to clang-rename.

Reviewers: alexfh

Differential Revision: https://reviews.llvm.org/D23058

llvm-svn: 277663

This was a shadowed variable error from the big Expression Parser plugin-ification.  I also 
added a test case for this.

<rdar://problem/27682376>

llvm-svn: 277662

rewriteOperands() always performed liveness queries at the base index
rather than the RegSlot/Base as apropriate for the machine operand. This
could lead to illegal rewriting in some cases.

llvm-svn: 277661

llvm-svn: 277660

llvm-svn: 277659

llvm-svn: 277658

for the llvm trunk change in r277656

llvm-svn: 277657

changing them to Expected<> to allow them to pass through llvm Errors.
No functional change.

This commit by itself will break the next lld builds.  I’ll be committing the
matching change for lld immediately next.

llvm-svn: 277656

This patch fixes pr25548.

Current implementation of PPCBoolRetToInt doesn't handle CallInst correctly, so it failed to do the intended optimization when there is a CallInst with parameters. This patch fixed that.

llvm-svn: 277655

This reverts commit r277610 / d619aa8878c3dafcc0d29a46517f63ff3209fdd4.

This make subtarget-no-movt.ll fail in
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_check/26892,

llvm-svn: 277654

In this for-loop, we append elements from one vector to another,
which is a bit inefficient.

llvm-svn: 277653

Not a correctness issue, but it would be nice if we didn't have to
recompute our block numbering (worst-case) every time we move MSSA.

llvm-svn: 277652

Limit the number of times the while(1) loop is executed. With this restriction
the number of hoisted instructions does not change in a significant way on the
test-suite.

Differential Revision: https://reviews.llvm.org/D23028

llvm-svn: 277651

With this patch we compute the DFS numbers of instructions only once and update
them during the code generation when an instruction gets hoisted.

Differential Revision: https://reviews.llvm.org/D23021

llvm-svn: 277650

With this patch we compute the MemorySSA once and update it in the code generator.

Differential Revision: https://reviews.llvm.org/D22966

llvm-svn: 277649

Some of these tests need to be cleaned up further to make it obvious
what they're testing, but as a first step remove all instances of
"grep".

llvm-svn: 277648

The size of image type is reported incorrectly as size of a pointer to address space 0, which causes error when casting image type to pointers by __builtin_astype.

The fix is to get image address space from TargetInfo then report the size accordingly.

Differential Revision: https://reviews.llvm.org/D22927

llvm-svn: 277647

getELFKind was overloaded with bitcode files and regular object files,
and I found that is a bit confusing. This patch renames them.

llvm-svn: 277646

llvm-svn: 277645

Also removes redundant variables. NFC.

llvm-svn: 277644

This patch adds "-m elf_iamcu" to ldd for IAMCU psABI:
https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI

Patch by H.J Lu.

llvm-svn: 277643

This reverts commit r277611 and the followup r277614.

Bootstrap builds and chromium builds are crashing during inlining after
this change.

llvm-svn: 277642

Didn't want to fold this in with r277640, since it touches bits that
aren't entirely related to r277640.

llvm-svn: 277641

This is a follow-up to r277637. It teaches MemorySSA that invariant
loads (and loads of provably constant memory) are always liveOnEntry.

llvm-svn: 277640

llvm-svn: 277638

This patch makes MemorySSA recognize atomic/volatile loads, and makes
MSSA treat said loads specially. This allows us to be a bit more
aggressive in some cases.

Administrative note: Revision was LGTM'ed by reames in person.
Additionally, this doesn't include the `invariant.load` recognition in
the differential revision, because I feel it's better to commit that
separately. Will commit soon.

Differential Revision: https://reviews.llvm.org/D16875

llvm-svn: 277637

I can't reproduce this buildbot failure locally, so temporarily remove this test while I investigate.

http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/27427

llvm-svn: 277636

Summary:
InstCombine unfolds expressions of the form `zext(or(icmp, icmp))` to `or(zext(icmp), zext(icmp))` such that in a later iteration of InstCombine the exposed `zext(icmp)` instructions can be optimized. We now combine this unfolding and the subsequent `zext(icmp)` optimization to be performed together. Since the unfolding doesn't happen separately anymore, we also again enable the folding of `logic(cast(icmp), cast(icmp))` expressions to `cast(logic(icmp, icmp))` which had been disabled due to its interference with the unfolding transformation.

Tested via `make check` and `lnt`.

Background
==========

For a better understanding on how it came to this change we subsequently summarize its history. In commit r275989 we've already tried to enable the folding of `logic(cast(icmp), cast(icmp))` to `cast(logic(icmp, icmp))` which had to be reverted in r276106 because it could lead to an endless loop in InstCombine (also see http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160718/374347.html). The root of this problem is that in `visitZExt()` in InstCombineCasts.cpp there also exists a reverse of the above folding transformation, that unfolds `zext(or(icmp, icmp))` to `or(zext(icmp), zext(icmp))` in order to expose `zext(icmp)` operations which would then possibly be eliminated by subsequent iterations of InstCombine. However, before these `zext(icmp)` would be eliminated the folding from r275989 could kick in and cause InstCombine to endlessly switch back and forth between the folding and the unfolding transformation. This is the reason why we now combine the `zext`-unfolding and the elimination of the exposed `zext(icmp)` to happen at one go because this enables us to still allow the cast-folding in `logic(cast(icmp), cast(icmp))` without entering an endless loop again.

Details on the submitted changes
================================

- In `visitZExt()` we combine the unfolding and optimization of `zext` instructions.
- In `transformZExtICmp()` we have to use `Builder->CreateIntCast()` instead of `CastInst::CreateIntegerCast()` to make sure that the new `CastInst` is inserted in a `BasicBlock`. The new calls to `transformZExtICmp()` that we introduce in `visitZExt()` would otherwise cause according assertions to be triggered (in our case this happend, for example, with lnt for the MultiSource/Applications/sqlite3 and SingleSource/Regression/C++/EH/recursive-throw tests). The subsequent usage of `replaceInstUsesWith()` is necessary to ensure that the new `CastInst` replaces the `ZExtInst` accordingly.
- In InstCombineAndOrXor.cpp we again allow the folding of casts on `icmp` instructions.
- The instruction order in the optimized IR for the zext-or-icmp.ll test case is different with the introduced changes.
- The test cases in zext.ll have been adopted from the reverted commits r275989 and r276105.

Reviewers: grosser, majnemer, spatel

Subscribers: eli.friedman, majnemer, llvm-commits

Differential Revision: https://reviews.llvm.org/D22864



Contributed-by: Matthias Reisinger <d412vv1n@gmail.com>
llvm-svn: 277635

Patch by Aditya Kumar.

Differential Revision: https://reviews.llvm.org/D22967

llvm-svn: 277634

Follow-up to r277596.

llvm-svn: 277633

Summary:
-lowertypetests-bitsets-level controls which kinds of bitsets
are generated, as introduced in r277556. This change adds tests
to compiler-rt.

Reviewers: kcc

Differential Revision: https://reviews.llvm.org/D23103

llvm-svn: 277632

We currently only support combining target shuffles that consist of a single source input (plus elements known to be undef/zero).

This patch generalizes the recursive combining of the target shuffle to collect all the inputs, merging any duplicates along the way, into a full set of src ops and its shuffle mask.

We uncover a number of cases where we have failed to combine a unary shuffle because the input has been duplicated and separated during lowering.

This will allow us to combine to 2-input shuffles in a future patch.

Differential Revision: https://reviews.llvm.org/D22859

llvm-svn: 277631

This reverts commit the revert commit r277627. The build errors
mentioned in r277627 were likely caused by an unclean build directory.
Sorry for the noise.

llvm-svn: 277630

This removes the restriction for the icmp constant, but as noted by the FIXME comments, 
we still need to change individual checks for binop operand constants.

llvm-svn: 277629

This reverts commit r277540. It breaks the build with:

../lib/Object/Archive.cpp:264:41: error: return type of out-of-line definition of 'llvm::object::ArchiveMemberHeader::getUID' differs from that in the declaration
Expected<unsigned> ArchiveMemberHeader::getUID() const {
~~~~~~~~~~~~~~~~~~                      ^
include/llvm/Object/Archive.h:53:12: note: previous declaration is here
  unsigned getUID() const;
  ~~~~~~~~ ^

llvm-svn: 277627

llvm-svn: 277626

This is a fix for PR28697.

An MDNode can indirectly refer to a GlobalValue, through a
ConstantAsMetadata.  When the GlobalValue is deleted, the MDNode operand
is reset to `nullptr`.  If the node is uniqued, this can lead to a
hard-to-detect cache invalidation in a Metadata map that's shared across
an LLVMContext.

Consider:

 1. A map from Metadata* to `T` called RemappedMDs.
 2. A node that references a global variable, `!{i1* @GV}`.
 3. Insert `!{i1* @GV} -> SomeT` in the map.
 4. Delete `@GV`, leaving behind `!{null} -> SomeT`.

Looking up the generic and uninteresting `!{null}` gives you `SomeT`,
which is likely related to `@GV`.  Worse, `SomeT`'s lifetime may be tied
to the deleted `@GV`.

This occurs in practice in the shared ValueMap used since r266579 in the
IRMover.  Other code that handles more than one Module (with different
lifetimes) in the same LLVMContext could hit it too.

The fix here is a partial revert of r225223: in the rare case that an
MDNode operand is a ConstantAsMetadata (i.e., wrapping a node from the
Value hierarchy), drop uniquing if it gets replaced with `nullptr`.
This changes step #4 above to leave behind `distinct !{null} -> SomeT`,
which can't be confused with the generic `!{null}`.

In theory, this can cause some churn in the LLVMContext's MDNode
uniquing map when Values are being deleted.  However:

  - The number of GlobalValues referenced from uniqued MDNodes is
    expected to be quite small.  E.g., the debug info metadata schema
    only references GlobalValues from distinct nodes.

  - Other Constants have the lifetime of the LLVMContext, whose teardown
    is careful to drop references before deleting the constants.

As a result, I don't expect a compile time regression from this change.

llvm-svn: 277625

Currently we have a number of tests that fail with -verify-machineinstrs.
To detect this cases earlier we add the option to the testcases with the
exception of tests that will currently fail with this option. PR 27456 keeps
track of this failures.

No code review, as discussed with Hal Finkel.

llvm-svn: 277624