1. Use a worklist, not a recursive approach, to avoid needless
   revisitation and being repeatedly forced to jump back to the
   start of the BB if a handle is invalidated.

2. Only insert operands to the worklist if they become unused
   after a dead instruction is removed, so we don’t have to
   visit them again in most cases.

3. Use a SmallSetVector to track the worklist.

4. Instead of pre-initting the SmallSetVector like in
   DeadCodeEliminationPass, only put things into the worklist
   if they have to be revisited after the first run-through.
   This minimizes how much the actual SmallSetVector gets used,
   which saves a lot of time.

llvm-svn: 248727

llvm-svn: 248726

Summary:
The P5600 is an out-of-order, superscalar implementation of the MIPS32R5
architecture.

The scheduler has a few missing details (see the 'Tricky Instructions'
section and some quirks of the P5600 are deliberately omitted due to
implementation difficulty and low chance of significant benefit (e.g. the
predicate on P5600WriteEitherALU). However, testing on SingleSource is
showing significant performance benefits on some apps (seven in the 10-30%
range) and only one significant regression (12%) when
-pre-RA-sched=linearize is given. Without -pre-RA-sched=linearize the
results are more variable. Some do even better (up to 55% improvement) but
increased numbers of copies are slowing others down (up to 12%).

Overall, the scheduler as it currently stands is a 2.4% win with
-pre-RA-sched=linearize and a 2.7% win without -pre-RA-sched=linearize.
I'm sure we can improve on this further.

For completeness, the FPGA this was tested on shows some failures with and
without the P5600 scheduler. These appear to be scheduling related since
the two test runs have fairly different sets of failing tests even after
accounting for other factors (e.g. spurious connection failures) however
it's not P5600 specific since we also get some for the generic scheduler.

Reviewers: vkalintiris

Subscribers: mpf, llvm-commits, atrick, vkalintiris

Differential Revision: http://reviews.llvm.org/D12193

llvm-svn: 248725

llvm-svn: 248724

Summary:
compile_commands.json is usually generated in the build directory.
Projects like LLVM/Clang enforce out-of-source builds.
This option allow allow such projects to work out of the box, without
moving the compilation database manually.

The naming of the option is similar to the one use by other tools:

    clang-{check,modernize,query,rename,tidy} -p=<build_path> <...>

Reviewers: alexfh

Differential Revision: http://reviews.llvm.org/D13199

llvm-svn: 248723

llvm-svn: 248722

Reviewed By: hfinkel

Differential Revision: http://reviews.llvm.org/D12853

llvm-svn: 248721

llvm-svn: 248720

This was split off of http://reviews.llvm.org/D13040 to make it easier to test the correctness of the implication logic. For the moment, this only handles a single easy case which shows up when eliminating and combining range checks. In the (near) future, I plan to extend this for other cases which show up in range checks, but I wanted to make those changes incrementally once the framework was in place.

At the moment, the implication logic will be used by three places. One in InstSimplify (this review) and two in SimplifyCFG (http://reviews.llvm.org/D13040 & http://reviews.llvm.org/D13070). Can anyone think of other locations this style of reasoning would make sense?

Differential Revision: http://reviews.llvm.org/D13074

llvm-svn: 248719

Originally, debug intrinsics and annotation intrinsics may prevent
the loop to be rerolled, now they are ignored.

Differential Revision: http://reviews.llvm.org/D13150

llvm-svn: 248718

While debugging, this makes it easier to understand due to which memory
reference these stores have been introduced.

llvm-svn: 248717

llvm-svn: 248716

Reviewers: rafael, ruiu

Subscribers: llvm-commits

Projects: #lld

Differential Revision: http://reviews.llvm.org/D13209

llvm-svn: 248715

JavaScript allows keywords to appear in IdenfierName positions, e.g.
fields, or object literal members, but not as plain identifiers.

Patch by Martin Probst. Thank you!

llvm-svn: 248714

Patch by Martin Probst. Thank you!

llvm-svn: 248713

Instructions which we can synthesis from a SCEV expression are not generated
directly, but only when they are used as an operand of another instruction. This
avoids generating unnecessary instruction and works more reliably than first
inserting them and then deleting them later on.

Suggested-by: Johannes Doerfert <doerfert@cs.uni-saarland.de>

Differential Revision: http://reviews.llvm.org/D13208

llvm-svn: 248712

llvm-svn: 248711

It is already installed by the autotools build, and it is useful for
developers who are not working on LLVM/Clang itself.

llvm-svn: 248710

llvm-svn: 248709

Patch by Igor Kudrin!

llvm-svn: 248708

llvm-svn: 248707

Differential Revision: http://reviews.llvm.org/D10539

llvm-svn: 248706

llvm-svn: 248705

llvm-svn: 248704

supportsTailCall() has two callers. Both of them double-check isThumb1Only(),
and refuse to proceed with tail-calling in that case.
Therefore, it makes sense to move this check to
ARMSubtarget::initSubtargetFeatures, where SupportsTailCall is initialized;
and to eliminate the extra checks at the call sites.

Following a review comment, added an "assert(supportsTailCall())"
in IsEligibleForTailCall.

NFC.

llvm-svn: 248703

This fix is not correct on its own until D12968 is resolved. Will resumbit once that is done.

llvm-svn: 248702

  This patch allows switch instructions with affine conditions in the
  SCoP. Also switch instructions in non-affine subregions are allowed.
  Both did not require much changes to the code, though there was some
  refactoring needed to integrate them without code duplication.

  In the llvm-test suite the number of profitable SCoPs increased from
  135 to 139 but more importantly we can handle more benchmarks and user
  inputs without preprocessing.

Differential Revision: http://reviews.llvm.org/D13200

llvm-svn: 248701

This is to level the ground a little bit, in preparation for the changes in http://reviews.llvm.org/D13081.

Code factorization replaces all insertions to NamingCheckFailures map with a unique addUsage function that does the job.
There is also no more difference between the declaration and the references to a given identifier, both cases are treated as ranges in the Usage vector. There is also a check to avoid duplicated ranges to be inserted, which sometimes triggered erroneous replacements.

References can now also be added before the declaration of the identifier is actually found; this looks to be the case for example when a templated class uses its parameters to specialize its templated base class.

Patch by Beren Minor!

Differential revision: http://reviews.llvm.org/D13079

llvm-svn: 248700

llvm-svn: 248699

When AA is being used, non-aliasing stores are canonicalized to use the same
chain, and DAGCombiner::getStoreMergeAndAliasCandidates can take advantage of
this by looking only as users of a store's chain operand. However, user
iteration is not result-number specific, we need to check that the use is as a
chain operand, and not via some other operand. It is certainly possible to have
another potentially-aliasing store, which shares the first's base pointer, and
uses the first's chain's node via some other operand.

Failure to catch this situation caused, at least in the included test case, an
assert later because the relative sequence-number ordering caused later
replacement to create a cycle in the DAG.

llvm-svn: 248698

llvm-svn: 248697

Parsing and sema analysis for 'simd' clause in 'ordered' directive.
Description
If the simd clause is specified, the ordered regions encountered by any thread will use only a single SIMD lane to execute the ordered
regions in the order of the loop iterations.
Restrictions
An ordered construct with the simd clause is the only OpenMP construct that can appear in the simd region

llvm-svn: 248696

  This check was needed at some point but seems not useful anymore. Only
  one adjustment in the domain generation was needed to cope with the
  cases this check prevented from happening before.

llvm-svn: 248695

llvm-svn: 248694

llvm-svn: 248693

When llvm declarations have argument names, it's helpful to actually
print those names when debugging. Arguably, it'd be nice to print them
all the time, but that would mean the IR we output wouldn't round trip
through bitcode, which doesn't store the names.

Make the varous print() methods in AsmWriter optionally print "for
debug" and set that flag in the dump() methods. The only thing this
does differently for now is print the argument names in declarations.

llvm-svn: 248692

llvm-svn: 248691

Before this change `HasSameValue` would return true for distinct
`alloca` instructions if they happened to be allocating the same
type (`alloca` instructions are not specified as reading memory).  This
change adds an explicit whitelist of instruction types for which
"identical" instructions compute the same value.

Fixes PR24952.

llvm-svn: 248690

This is one step towards solving PR24766:
https://llvm.org/bugs/show_bug.cgi?id=24766

We were not producing the same IR for these two C functions because the store
to the temp bool causes extra zexts:

#include <stdbool.h>

bool switchy(char x1, char x2, char condition) {
   bool conditionMet = false;
   switch (condition) {
   case 0: conditionMet = (x1 == x2); break;
   case 1: conditionMet = (x1 <= x2); break;
   }
   return conditionMet;
}

bool switchy2(char x1, char x2, char condition) {
   switch (condition) {
   case 0: return (x1 == x2);
   case 1: return (x1 <= x2);
   }
  return false;
}

As noted in the code comments, this test case manages to avoid the more general existing
phi optimizations where there are only 2 phi inputs or where there are no constant phi 
args mixed in with the casts ops. It seems like a corner case, but if we don't catch it, 
then I don't think we can get SimplifyCFG to further optimize towards the canonical form
for this function shown in the bug report.

Differential Revision: http://reviews.llvm.org/D12866

llvm-svn: 248689

We now only delete trivially dead instructions in the BB we copy (copyBB), but
not in any other BB.  Only for copyBB we know that there will _never_ be any
future uses of instructions that have no use after copyBB has been generated.
Other instructions in the AST that have been generated by IslNodeBuilder may
look dead at the moment, but may possibly still be referenced by GlobalMaps. If
we delete them now, later uses would break surprisingly.

We do not have a test case that breaks due to us deleting too many instructions.
This issue was found by inspection.

llvm-svn: 248688