definition below all of the header #include lines, lib/Support edition.

llvm-svn: 206847

definition below all of the header #include lines, TableGen edition.

llvm-svn: 206846

definition below all the header #include lines. This updates most of the
miscellaneous other lib/... directories. A few left though.

llvm-svn: 206845

definition below all of the header #include lines, lib/Transforms/...
edition.

This one is tricky for two reasons. We again have a couple of passes
that define something else before the includes as well. I've sunk their
name macros with the DEBUG_TYPE.

Also, InstCombine contains headers that need DEBUG_TYPE, so now those
headers #define and #undef DEBUG_TYPE around their code, leaving them
well formed modular headers. Fixing these headers was a large motivation
for all of these changes, as "leaky" macros of this form are hard on the
modules implementation.

llvm-svn: 206844

definition below all the header #include lines, lib/Analysis/...
edition.

This one has a bit extra as there were *other* #define's before #include
lines in addition to DEBUG_TYPE. I've sunk all of them as a block.

llvm-svn: 206843

definition below all of the header #include lines, lib/Target/...
edition.

llvm-svn: 206842

after including the generated code from tablegen.

llvm-svn: 206841

of a '.inc' file before including actual headers. In this case we had
both duplicated a header's include and were including a standard header.

llvm-svn: 206840

llvm-svn: 206839

system headers above the includes of generated '.inc' files that
actually contain code. In a few targets this was already done pretty
consistently, but it wasn't done *really* consistently anywhere. It is
strictly cleaner IMO and necessary in a bunch of places where the
DEBUG_TYPE is referenced from the generated code. Consistency with the
necessary places trumps. Hopefully the build bots are OK with the
movement of intrin.h...

llvm-svn: 206838

define below all header includes in the lib/CodeGen/... tree. While the
current modules implementation doesn't check for this kind of ODR
violation yet, it is likely to grow support for it in the future. It
also removes one layer of macro pollution across all the included
headers.

Other sub-trees will follow.

llvm-svn: 206837

while checking candidate for bit field extract.
Otherwise the value may not fit in uint64_t and this will trigger an
assertion.

This fixes PR19503.

llvm-svn: 206834

and PPC, but not x86.

llvm-svn: 206830

llvm-svn: 206828

ELFEntityIterator does not implement RandomAccessIterator. It does
not even implement BidirectionalIterator.

This patch fixes LLD build issue when compiled with MSVC2013 with
debug: MSVC's find_if checks if the start iterator is before the end
iterator in the sense of operator< if it declares implementing
RandomAccessIterator. If a class does not have operator<, it fails
to compile.

llvm-svn: 206825

llvm-svn: 206824

behavior based on other files defining DEBUG_TYPE, which means it cannot
define DEBUG_TYPE at all. This is actually better IMO as it forces folks
to define relevant DEBUG_TYPEs for their files. However, it requires all
files that currently use DEBUG(...) to define a DEBUG_TYPE if they don't
already. I've updated all such files in LLVM and will do the same for
other upstream projects.

This still leaves one important change in how LLVM uses the DEBUG_TYPE
macro going forward: we need to only define the macro *after* header
files have been #include-ed. Previously, this wasn't possible because
Debug.h required the macro to be pre-defined. This commit removes that.
By defining DEBUG_TYPE after the includes two things are fixed:

- Header files that need to provide a DEBUG_TYPE for some inline code
  can do so by defining the macro before their inline code and undef-ing
  it afterward so the macro does not escape.

- We no longer have rampant ODR violations due to including headers with
  different DEBUG_TYPE definitions. This may be mostly an academic
  violation today, but with modules these types of violations are easy
  to check for and potentially very relevant.

Where necessary to suppor headers with DEBUG_TYPE, I have moved the
definitions below the includes in this commit. I plan to move the rest
of the DEBUG_TYPE macros in LLVM in subsequent commits; this one is big
enough.

The comments in Debug.h, which were hilariously out of date already,
have been updated to reflect the recommended practice going forward.

llvm-svn: 206822

llvm-svn: 206821

Removes some extra manual dynamic memory allocation/management. It does
get a bit quirky having to make State's members mutable and
pointers/references to const rather than non-const, but that's a
necessary workaround to dealing with the std::set elements.

llvm-svn: 206807

llvm-svn: 206803

The comment claimed that the register class information wasn't available
in the assembly parser, but that's not really true. It's just annoying to
get to. Replace the helper functions with references to the auto-generated
information.

llvm-svn: 206802

With a constant mask a vpermil* is just a shufflevector. This patch implements
that simplification. This allows us to produce denser code. It should also
allow more folding down the line.

llvm-svn: 206801

llvm-svn: 206800

Make sure only general purpose registers are valid for offset regs and
that 32-bit regs are only valid for sxtw and uxtw extends.

llvm-svn: 206799

No functional change.

llvm-svn: 206798

The canonical form for the extended addressing mode (e.g.,
"[x1, w2, uxtw #3]" is for the MCInst to have the second register be the
full 64-bit GPR64 register class. The instruction printer cleans up
the output for display to show the 32-bit register instead, per the
specification.

This simplifies 205893 now that the aliasing is handled in the printer
in 206495 so that the codegen path and the disassembler path give the
same MCInst form.

llvm-svn: 206797

llvm-svn: 206796

The rationale for this artificial dependency seems to have been lost to the
ravages of time, it is covered by no regression tests, and has no impact on
test-suite performance numbers on either x86 or PPC.

For the test suite, on both x86 and PPC, I ran the test suite 10 times (both as
a baseline and with this change), and found no statistically-significant
changes.  For PPC, I used a P7 box. For x86, I used an Intel Xeon E5430. Both
with -O3 -mcpu=native.

This was discussed on-list back in January, but I've not had a chance to run
the performance tests until today.

llvm-svn: 206795

This avoids copying the container by simply deleting until empty.

While I'd rather move to a stricter ownership semantic (unique_ptr),
SmallPtrSet can't cope with unique_ptr and the ownership semantics here
are a bit incestuous (Module sort of owns itself, but sort of doesn't
(if the LLVMContext is destroyed before the Module, then it deregisters
itself from the context... )).

Ideally Modules would be given to the context, or possibly an
emplace-like function to construct them there. Modules then shouldn't be
destroyed by LLVM API clients, but by interacting with the owner
(LLVMContext) directly (but even then, passing a Module* to LLVMContext
doesn't provide an easy way to destroy the Module, since the set would
be over unique_ptrs and you'd need a heterogenous lookup function which
SmallPtrSet doesn't have either).

llvm-svn: 206794

With this MC is able to handle _GLOBAL_OFFSET_TABLE_ in 64 bit mode, which is
needed for medium and large code models.

This fixes pr19470.

llvm-svn: 206793

No functionality change, it will just make the next patch easier to read.

llvm-svn: 206792

llvm-svn: 206790

The -tailcallelim pass should be checking if byval or inalloca args can
be captured before marking calls as tail calls.  This was the real root
cause of PR7272.

With a better fix in place, revert the inliner change from r105255.  The
test case it introduced still passes and has been moved to
test/Transforms/Inline/byval-tail-call.ll.

Reviewers: chandlerc

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

llvm-svn: 206789

llvm-svn: 206788

llvm-svn: 206786

llvm-svn: 206785

llvm-svn: 206784

Requires switching some vectors to lists to maintain pointer validity.
These could be changed to forward_lists (singly linked) with a bit more
work - I've left comments to that effect.

llvm-svn: 206780

Summary:
The INSERTPS pattern fragment was called insrtps (mising 'e'), which
would make it harder to grep for the patterns related to this instruction.
Renaming it to use the proper instruction name.

Reviewers: nadav

CC: llvm-commits

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

llvm-svn: 206779

cpp file rather than in the header and then again in the cpp file.

llvm-svn: 206778