llvm-svn: 171866

llvm-svn: 171863

PR14782

llvm-svn: 171846

Current targets don't have more than 256 relocations so they don't hit this
limit, but ELF64 actually allows more than 8 bits for a relocation type. These
were being truncated on AArch64.

llvm-svn: 171845

one file where it is called as a static function. Nuke the declaration
and the definition in lib/CodeGen, along with the include of
SelectionDAG.h from this file.

There is no dependency edge from lib/CodeGen to
lib/CodeGen/SelectionDAG, so it isn't valid for a routine in lib/CodeGen
to reference the DAG. There is a dependency from
lib/CodeGen/SelectionDAG on lib/CodeGen. This breaks one violation of
this layering.

llvm-svn: 171842

Suggested by Dave Blaikie.

llvm-svn: 171839

This closes PR14709 and hopefully is a small step towards preventing
similar issues in the future.

llvm-svn: 171837

make sure that vector types do work.

llvm-svn: 171833

llvm-svn: 171832

llvm-svn: 171829

llvm-svn: 171826

No change in functionality.

llvm-svn: 171822

llvm-svn: 171821

Previously, 4 bits were unused.

llvm-svn: 171814

This shrinks MachineInstr to 64 bytes (from 72).

llvm-svn: 171813

llvm-svn: 171812

make into the last commit.

Also, update the test-generation script to generate an exhaustive test for
align_to_end as well, and include the generated test.

llvm-svn: 171811

Thank Eric Christopher for figuring out these problems!

llvm-svn: 171805

llvm-svn: 171804

llvm-svn: 171803

LoopVectorizer: When we vectorizer and widen loops we process many elements at once. This is a good thing, except for
small loops. On small loops post-loop that handles scalars (and runs slower) can take more time to execute than the
rest of the loop. This patch disables widening of loops with a small static trip count.

llvm-svn: 171798

bundling. The document describing this feature and the implementation has also
been updated:

https://sites.google.com/a/chromium.org/dev/nativeclient/pnacl/aligned-bundling-support-in-llvm

llvm-svn: 171797

  o. X/C1 * C2 => X * (C2/C1) (if C2/C1 is neither special FP nor denormal)
  o. X/C1 * C2 -> X/(C1/C2)   (if C2/C1 is either specical FP or denormal, but C1/C2 is a normal Fp)

     Let MDC denote multiplication or dividion with one & only one operand being a constant
  o. (MDC ± C1) * C2 => (MDC * C2) ± (C1 * C2)
     (so long as the constant-folding doesn't yield any denormal or special value)

llvm-svn: 171793

llvm-svn: 171791

llvm-svn: 171790

s/X86/ARM/

llvm-svn: 171789

parsing MS-style inline assembly.

llvm-svn: 171784

llvm-svn: 171780

proposal. This leaves the strings in the skeleton die as strp,
but in all dwo files they're accessed now via DW_FORM_GNU_str_index.

Add support for dumping these sections and modify the fission-cu.ll
testcase to have the correct strings and form. Fix a small bug
in the fixed form sizes routine that involved out of array accesses
for the table and add a FIXME in the extractFast routine to fix
this up.

llvm-svn: 171779

code generation.  Variables addressed through a GlobalAlias were not being
handled, and variables with available_externally linkage were treated
incorrectly.  The patch contains two new tests to verify the correct code
generation for these cases.

llvm-svn: 171778

This is necessary not only for representing empty ranges, but for handling
multibyte characters in the input. (If the end pointer in a range refers to
a multibyte character, should it point to the beginning or the end of the
character in a char array?) Some of the code in the asm parsers was already
assuming this anyway.

llvm-svn: 171765

llvm-svn: 171764

turning a code like this:

if (foo)
   free(foo)

into that:
free(foo)

Move a call to free from basic block FB into FB's predecessor, P,
when the path from P to FB is taken only if the argument of free is
not equal to NULL.

Some restrictions apply on P and FB to be sure that this code motion
is profitable. Namely:
1. FB must have only one predecessor P.
2. FB must contain only the call to free plus an unconditional
   branch to S.
3. P's successors are FB and S.

Because of 1., we will not increase the code size when moving the call
to free from FB to P.
Because of 2., FB will be empty after the move.
Because of 2. and 3., P's branch instruction becomes useless, so as FB
(simplifycfg will do the job).

llvm-svn: 171762

llvm-svn: 171759

llvm-svn: 171758

llvm-svn: 171749

library rename.

llvm-svn: 171747

implementation lives already.

llvm-svn: 171746

builder these days, and this thing hasn't seen updates for a very long
time.

llvm-svn: 171741

peculiar headers under include/llvm.

This struct still doesn't make a lot of sense, but it makes more sense
down in TargetLowering than it did before.

llvm-svn: 171739