This will make the transition to unique_ptr easier by allowing more
incremental changes.

llvm-svn: 202949

llvm-svn: 202946

llvm-svn: 202945

Patchpoints already did this. Doing it for stackmaps is a convenience
for the runtime in the event that it needs to scratch register to
patch or perform a runtime call thunk.

Unlike patchpoints, we just assume the AnyRegCC calling
convention. This is the only language and target independent calling
convention specific to stackmaps so makes sense.  Although the calling
convention is not currently used to select the scratch registers.

llvm-svn: 202943

llvm-svn: 202939

llvm-svn: 202937

Patch by Manuel Jacob.

llvm-svn: 202936

Found self-hosting clang-cl on windows. :)

llvm-svn: 202935

llvm-svn: 202932

selection dag (PR19012)

In X86SelectionDagInfo::EmitTargetCodeForMemcpy we check with MachineFrameInfo
to make sure that ESI isn't used as a base pointer register before we choose to
emit rep movs (which clobbers esi).

The problem is that MachineFrameInfo wouldn't know about dynamic allocas or
inline asm that clobbers the stack pointer until SelectionDAGBuilder has
encountered them.

This patch fixes the problem by checking for such things when building the
FunctionLoweringInfo.

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

llvm-svn: 202930

The correct name of the type in LLVM assembly is "x86_mmx".  Also remove
the reST label "t_x86mmx" because it was unused anyway.

Patch by Manuel Jacob!

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

llvm-svn: 202929

Patch by Manuel Jacob!

llvm-svn: 202928

The distinction between "identified" and "literal" struct types is fully
documented in a later section.

Patch by Philip Reames!

llvm-svn: 202927

llvm-svn: 202926

llvm-svn: 202924

itself and teach it to convert between the non-const and const variants.
De-templatetize its usage in APIs to just use the const variant which
always works for those use cases. Also, rename its implementation to
reflect that it is an iterator over *users* not over *uses*.

This is a step toward providing both iterator and range support for
walking the *uses* distinct from the *users*. In a subsequent patch this
will get renamed to make it clear that this is an adaptor over the
fundamental use iterator.

llvm-svn: 202923

using a full uint16_t with the flag value... which happens to be
0 or 1. Update the class for bool values and rename functions slightly.

llvm-svn: 202921

llvm-svn: 202920

llvm-svn: 202919

llvm-svn: 202918

llvm-svn: 202917

I did not intend to cast a pointer to ulittle32_t there because the return
type is const void*.

llvm-svn: 202916

Looks like llvm-readobj is the only customer of this code, and apparently
there's no test to cover this function. I'll write it after finishing
plumbing from llvm-objdump to there.

llvm-svn: 202915

llvm-svn: 202914

llvm-svn: 202913

Currently this code is duplicated across visitSHL, visitSRA and visitSRL.  The
plan is to add rotates as clients to this new function.

There is no functional change intended here.

llvm-svn: 202908

llvm-svn: 202905

llvm-svn: 202902

llvm-svn: 202895

llvm-svn: 202883

Unwind info contents were indented at the same level as function table
contents. That's a bit confusing because the unwind info is pointed by
function table. In other places we usually increment indentation depth
by one when dereferncing a pointer.

This patch also removes extraneous newlines between function tables.

llvm-svn: 202879

llvm-svn: 202875

This is required to include MSVC's <atomic> header, which we do now in
LLVM.

Tests forthcoming in Clang, since that's where we test semantic inline
asm changes.

llvm-svn: 202865

llvm-svn: 202863

llvm-svn: 202862

Register the Asm Printer for the ppc64le target.

This fills in a spot that was missed in an earlier change (r187179).

llvm-svn: 202861

Previously for:

tail call void inttoptr (i64 65536 to void ()*)() nounwind

We would emit:

bl 65536

The immediate operand of the bl instruction is a relative offset so it is
wrong to use the absolute address here.

llvm-svn: 202860

llvm-svn: 202858

llvm-svn: 202857

Summary:
Previously, attempting to extract lanes 2 and 3 would actually extract lane 1.
The MSA CodeGen tests only covered lanes 0 and 1.

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

llvm-svn: 202848