llvm-svn: 142736

elimination on them too.

llvm-svn: 142735

able to constant fold load instructions where the argument is a constant.
Second, we should be able to watch multiple PHI nodes through the loop; this
patch only supports PHIs in loop headers, more can be done here.

With this patch, we now constant evaluate:
  static const int arr[] = {1, 2, 3, 4, 5};
  int test() {
    int sum = 0;
    for (int i = 0; i < 5; ++i) sum += arr[i];
    return sum;
  }

llvm-svn: 142731

SHL inserts zeros from the right, thus even when the original
sign_extend_inreg value was of 1-bit, we need to sra.

llvm-svn: 142724

llvm-svn: 142704

llvm-svn: 142691

llvm-svn: 142684

llvm-svn: 142682

llvm-svn: 142675

Extend instcombine's shufflevector simplification to handle more cases where the input and output vectors have different sizes.  Patch by Xiaoyi Guo.

llvm-svn: 142671

Next step in the ongoing saga of NEON load/store assmebly parsing. Handle
VLD1 instructions that take a two-register register list.

Adjust the instruction definitions to only have the single encoded register
as an operand. The super-register from the pseudo is kept as an implicit def,
so passes which come after pseudo-expansion still know that the instruction
defines the other subregs.

llvm-svn: 142670

ZExtPromotedInteger and SExtPromotedInteger based on the operation we legalize.

SetCC return type needs to be legalized via PromoteTargetBoolean.

llvm-svn: 142660

all x86 systems. Sorry for the breakage.

llvm-svn: 142656

2. Fix a typo in CONCAT_VECTORS which exposed the bug in #1.

llvm-svn: 142648

it's a bit more plausible to use this instead of CodePlacementOpt. The
code for this was shamelessly stolen from CodePlacementOpt, and then
trimmed down a bit. There doesn't seem to be much utility in returning
true/false from this pass as we may or may not have rewritten all of the
blocks. Also, the statistic of counting how many loops were aligned
doesn't seem terribly important so I removed it. If folks would like it
to be included, I'm happy to add it back.

This was probably the most egregious of the missing features, and now
I'm going to start gathering some performance numbers and looking at
specific loop structures that have different layout between the two.

Test is updated to include both basic loop alignment and nested loop
alignment.

llvm-svn: 142645

canonical example I used when developing it, and is one of the primary
motivating real-world use cases for __builtin_expect (when burried under
a macro).

I'm working on more test cases here, but I'm trying to make sure both
that the pass is doing the right thing with the test cases and that they
aren't too brittle to changes elsewhere in the code generation pipeline.

Feedback and/or suggestions on how to test this are very welcome.
Especially feedback on whether testing the block comments is a good
strategy; I couldn't find any good examples to steal from but all the
other ideas I had were a lot uglier or more fragile.

llvm-svn: 142644

Remove intrinsics for X86 BLSI, BLSMSK, and BLSR intrinsics and replace with custom isel lowering code.

llvm-svn: 142642

llvm-svn: 142626

llvm-svn: 142624

llvm-svn: 142622

llvm-svn: 142583

llvm-svn: 142582

llvm-svn: 142581

Refactor code from inlining and globalopt that checks whether a function definition is unused, and enhance it so it can tell that functions which are only used by a blockaddress are in fact dead.  This probably doesn't happen much on most code, but the Linux kernel's _THIS_IP_ can trigger this issue with blockaddress.  (GlobalDCE can also handle the given tescase, but we only run that at -O3.)  Found while looking at PR11180.

llvm-svn: 142572

correctly in GetStringLength, fixing PR11181!

llvm-svn: 142558

llvm-svn: 142557

llvm-svn: 142550

When checking the availability of instructions using the TLI, a 'promoted'
instruction IS available. It means that the value is bitcasted to another type
for which there is an operation. The correct check for the availablity of an
instruction is to check if it should be expanded.

llvm-svn: 142542

llvm-svn: 142537

Use literal pool loads instead of MOVW/MOVT for materializing global addresses when optimizing for size.

On spec/gcc, this caused a codesize improvement of ~1.9% for ARM mode and ~4.9% for Thumb(2) mode. This is
codesize including literal pools.

The pools themselves doubled in size for ARM mode and quintupled for Thumb mode, leaving suggestion that there
is still perhaps redundancy in LLVM's use of constant pools that could be decreased by sharing entries.

Fixes PR11087.

llvm-svn: 142530

This tests TableGen's paste functionality.

llvm-svn: 142526

Add a Value named "NAME" to each Record.  This will be set to the def or defm
name when instantiating multiclasses.  This will replace the #NAME# processing
hack once paste functionality is in place.

llvm-svn: 142518

and switches, with arbitrary numbers of successors. Still optimized for
the common case of 2 successors for a conditional branch.

Add a test case for switch metadata showing up in the BlockFrequencyInfo pass.

llvm-svn: 142493

encoding of probabilities. In the absense of metadata, it continues to
fall back on static heuristics.

This allows __builtin_expect, after lowering through llvm.expect
a branch instruction's metadata, to actually enter the branch
probability model. This is one component of resolving PR2577.

llvm-svn: 142492

layer already had support for printing the results of this analysis, but
the wiring was missing.

Now that printing the analysis works, actually bring some of this
analysis, and the BranchProbabilityInfo analysis that it wraps, under
test! I'm planning on fixing some bugs and doing other work here, so
having a nice place to add regression tests and a way to observe the
results is really useful.

llvm-svn: 142491

llvm-svn: 142488

llvm-svn: 142480

llvm-svn: 142462

llvm-svn: 142442

llvm-svn: 142434