This allows us to insert some hooks before emitting data into an actual object file.
For example, we can capture the register usage for a translation unit by overriding
the EmitInstruction method. The register usage information is needed to generate
.reginfo and .Mips.options ELF sections.
    
No functional changes.
    
Differential Revision: http://llvm-reviews.chandlerc.com/D3129

llvm-svn: 204917

llvm-svn: 204916

llvm-svn: 204915

llvm-svn: 204914

Clang-format now correctly formats:
  some_type<a * b> v;
  template <bool a, bool b> typename enabled_if<a && b>::type f() {}

llvm-svn: 204913

Transform:
    icmp X+Cst2, Cst
into:
    icmp X, Cst-Cst2
when Cst-Cst2 does not overflow, and the add has nsw.

llvm-svn: 204912

[mips] Stop caching the result of hasMips64(), isABI_O32(), isABI_N32(), and isABI_N64() from MipsSubTarget in MipsTargetLowering

Summary:
The short name is quite convenient so provide an accessor for them instead.

No functional change

Depends on D3177

Reviewers: matheusalmeida

Reviewed By: matheusalmeida

Differential Revision: http://llvm-reviews.chandlerc.com/D3178

llvm-svn: 204911

These don't seem to have any real point. Let's start with
IndexingContext. I can't come up with any conceivable reason to have
many hundereds of thousands of these alive in an address space which
would make the 4x difference in allocated (but unused) memory for the
string scratch buffer a significant memory usage problem.

The EditedSource one is somewhat more surprising. This is an 8x increase
in the memory allocated (but not used) per editted source file. However,
for this to realistically be a problem, you would need to have over half
a million editted source files in a single address space, and even that
would only really have problems on 32-bit Windows where you really only
have 2gb of virtual address space. And what's more important, the fix to
this if it is actually an issue shouldn't be to shrink the allocator's
size, it is to pass a single allocator into *many* edited source file
objects and let them share the memory.

These were the only two uses of custom sized BumpPtrAllocators
(excluding ones in the JIT using a custom allocation strategy) in all of
LLVM, Clang, LLD, LLDB, or Polly. I don't think we actually need this
complexity in the primary BumpPtrAllocator at all and am planning to
remove it.

llvm-svn: 204910

Reviewers: djasper, klimek

Reviewed By: djasper

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D3192

llvm-svn: 204909

differences from subsequent diffs, and ease review. Going to be
performing some major surgery to simplify this stuff.

llvm-svn: 204908

rewrite some of them to be more clear.

The terminology being used in our allocators is making me really sad. We
call things slab allocators that aren't at all slab allocators. It is
quite confusing.

llvm-svn: 204907

By Robert Khasanov rob.khasanov@gmail.com

llvm-svn: 204906

llvm-svn: 204905

llvm-svn: 204904

llvm-svn: 204903

llvm-svn: 204902

llvm-svn: 204901

llvm-svn: 204900

Fix description:
Expressions like 'cmp r0, #(l1 - l2) >> 3' could not be evaluated on asm parsing stage,
since it is impossible to resolve labels on this stage. In the end of stage we still have
expression (MCExpr).
Then, when we want to encode it, we expect it to be an immediate, but it still an expression.
Patch introduces a Fixup (MCFixup instance), that is processed after main encoding stage.

llvm-svn: 204899

solved as a constant at compilation time.

llvm-svn: 204898

llvm-svn: 204897

while I investigate as it seems to be causing issues with the gdb bot.

This reverts commit r204874.

llvm-svn: 204896

llvm-svn: 204895

llvm-svn: 204894

RelocationInfo argument.

llvm-svn: 204893

it to be out-of-line.

llvm-svn: 204892

they take ownership of the RelocationInfo they're constructed with.

llvm-svn: 204891

llvm-svn: 204890

llvm-svn: 204889

The LangRef warning wasn't formatting the way I intended it to anyway.

Surprisingly inalloca appears to work, even when optimizations are
enabled.  We generate very bad code for it, but we can self-host and run
lots of big tests.

llvm-svn: 204888

the type of the variable until it's known.

llvm-svn: 204887

Unbreak the sanitizer-x86_64-linux bot.

Change-Id: Ie03f1b93fae45c54b142003731ff4f5d4f6b62f8
llvm-svn: 204886

No functional change.

llvm-svn: 204885

and v4i64->v4f64.

The new costs match what we did for SSE2 and reflect the reality of our codegen.

<rdar://problem/16381225>

llvm-svn: 204884

This also finally removes a bogus call to AliasedSymbol.

llvm-svn: 204883

llvm-svn: 204882

It seems that gcov, when faced with a string that is apparently zero
length, just keeps reading words until it finds a length it likes
better. I'm not really sure why this is, but it's simple enough to
make llvm-cov follow suit.

llvm-svn: 204881

Fix the cost model to reflect the reality of our codegen.

rdar://16370633

llvm-svn: 204880

The section __DATA,__data is atomized by the linker and cannot have L symbols.

llvm-svn: 204879

When parsing MS inline assembly, we note that fpsw is an implicit def of
most x87 FP operations, and add it to the clobber list.  However, we
don't recognize fpsw as a gcc register name, and we assert.  Clang
always adds an fpsr clobber, which means the same thing to LLVM, so we
can just use that.

This test case was broken by my LLVM change r196939.

Reviewers: echristo

Differential Revision: http://llvm-reviews.chandlerc.com/D2993

llvm-svn: 204878