llvm-svn: 233942

Without this patch, we split the 256-bit vector into halves and produced something like:
	movzwl	(%rdi), %eax
	vmovd	%eax, %xmm0
	vxorps	%xmm1, %xmm1, %xmm1
	vblendps	$15, %ymm0, %ymm1, %ymm0 ## ymm0 = ymm0[0,1,2,3],ymm1[4,5,6,7]

Now, we eliminate the xor and blend because those zeros are free with the vmovd:
        movzwl  (%rdi), %eax
        vmovd   %eax, %xmm0

This should be the final fix needed to resolve PR22685:
https://llvm.org/bugs/show_bug.cgi?id=22685

llvm-svn: 233941

llvm-svn: 233940

Require the pointee type to be passed explicitly and assert that it is
correct. For now it's possible to pass nullptr here (and I've done so in
a few places in this patch) but eventually that will be disallowed once
all clients have been updated or removed. It'll be a long road to get
all the way there... but if you have the cahnce to update your callers
to pass the type explicitly without depending on a pointer's element
type, that would be a good thing to do soon and a necessary thing to do
eventually.

llvm-svn: 233938

Now the GEP constant utility functions require the type to be explicitly
passed (since eventually the pointer type will be opaque and not convey
the required type information). For now callers can still pass nullptr
(though none were needed here in Clang, which is nice) if
convenienc/necessary, but eventually that will be disallowed as well.

llvm-svn: 233937

Follow-up of r233653.

llvm-svn: 233936

Fix a crasher that could happen when you run LLDB and evaluate an expression where the objective C runtime registers a helper function, and also have an Objective C or C++ exception breakpoint. When shutting down the process in Process::Finalize() we clear a STL collection class and that causes objects to be destroyed that could re-enter Process and cause it to try to iterate over that same collection class that is being destroyed.

Guard against this by setting a new "m_finalizing" flag that lets us know we are in the process of finalizing.

<rdar://problem/20369152>

llvm-svn: 233935

Fix a few more test suite errors where a cleanup lambda was calling self.runCmd() which requires the command returns successfully. Using self.dbg.HandleCommand() doesn't require success.

llvm-svn: 233934

Many many test failures after some recent changes. The problem is lldbtest.getPlatform() returns the "OS" of the selected platform's triple. This is "macosx" for desktop macosx and "ios" for iOS. It used to be "darwin". 

There was a lot of code that was checking "if self.getPlatform() == 'darwin'" which is not correct. I fixed this by adding a:

lldbtest.platformIsDarwin()

which returns true if the current platform's OS is "macosx", "ios" or "darwin". These three valid darwin are now returned by a static function:

lldbtest.getDarwinOSTriples()

Fixed up all places that has 'if self.getPlatform() == "darwin":' with "if self.platformIsDarwin()" and all instances of 'if self.getPlatform() != "darwin":' with "if not self.platformIsDarwin()". I also fixed some darwin decorator functions to do the right thing as well.

llvm-svn: 233933

Follow-up to r233921 that removes the 'void *Aligner' Stmt union member
for MSVC 2013.

llvm-svn: 233932

[X86, AVX] adjust tablegen patterns to generate better code for scalar insertion into zero vector (PR23073)

For code like this:

define <8 x i32> @load_v8i32() {
  ret <8 x i32> <i32 7, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0>
}

We produce this AVX code:

_load_v8i32:                            ## @load_v8i32
  movl	$7, %eax
  vmovd	%eax, %xmm0
  vxorps	%ymm1, %ymm1, %ymm1
  vblendps	$1, %ymm0, %ymm1, %ymm0 ## ymm0 = ymm0[0],ymm1[1,2,3,4,5,6,7]
  retq

There are at least 2 bugs in play here:

    We're generating a blend when a move scalar does the same job using 2 less instruction bytes (see FIXMEs).
    We're not matching an existing pattern that would eliminate the xor and blend entirely. The zero bytes are free with vmovd.

The 2nd fix involves an adjustment of "AddedComplexity" [1] and mostly masks the 1st problem.

[1] AddedComplexity has close to no documentation in the source. 
The best we have is this comment: "roughly corresponds to the number of nodes that are covered". 
It appears that x86 has bastardized this definition by inflating its values for some other
undocumented reason. For example, we have a pattern with "AddedComplexity = 400" (!). 

I searched my way to this page:
https://groups.google.com/forum/#!topic/llvm-dev/5UX-Og9M0xQ

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

llvm-svn: 233931

llvm-svn: 233930

MSVC 2013 requires the argument to __declspec(align()) to be an integer
constant expression that doesn't involve any identifiers like sizeof.

For GCC and Clang, LLVM_PTR_SIZE is equivalent to __SIZEOF_POINTER__,
which dates back to GCC 4.6 and Clang 2010. If that's not available, we
get sizeof(void*), which works with alignas() and
__attribute__((aligned())).

For MSVC, LLVM_PTR_SIZE is 4 or 8 depending on _WIN64.

llvm-svn: 233929

This implementation was ported from the AMD builtin library
and has been tested with piglit, OpenCV, and the ocl conformance tests.

llvm-svn: 233928

This implementation was ported from the AMD builtin library
and has been tested with piglit, OpenCV, and the ocl conformance tests.

llvm-svn: 233927

This implementation was ported from the AMD builtin library
and has been tested with piglit, OpenCV, and the ocl conformance tests.

llvm-svn: 233926

This implementation was ported from the AMD builtin library
and has been tested with piglit, OpenCV, and the ocl conformance tests.

llvm-svn: 233925

No functional changes.

llvm-svn: 233924

It was documented as 8 and operator new[] defaults to 8, but the normal
operator new was never updated and happily wasted bytes on every other
allocation.

We still have to allocate all Types with 16 byte alignment, update the
allocation calls for Types that were missing explicit alignment.

llvm-svn: 233922

Previously we would waste 32 bits on alignment, use LLVM_ALIGNAS to
free that space for derived classes an place. Sadly still have to #ifdef
out MSVC 2013 because it can't align based on a sizeof expr.

No intended functionality change. New byte counts:
sizeof(before)			|	sizeof(after)

LabelStmt: 32			|	LabelStmt: 24
SwitchStmt: 48			|	SwitchStmt: 40
WhileStmt: 40			|	WhileStmt: 32
DoStmt: 40			|	DoStmt: 32
ForStmt: 64			|	ForStmt: 56
ContinueStmt: 16		|	ContinueStmt: 8
BreakStmt: 16			|	BreakStmt: 8
ReturnStmt: 32			|	ReturnStmt: 24
AsmStmt: 40			|	AsmStmt: 32
GCCAsmStmt: 80			|	GCCAsmStmt: 72
MSAsmStmt: 96			|	MSAsmStmt: 88
SEHExceptStmt: 32		|	SEHExceptStmt: 24
SEHFinallyStmt: 24		|	SEHFinallyStmt: 16
SEHLeaveStmt: 16		|	SEHLeaveStmt: 8
CapturedStmt: 32		|	CapturedStmt: 24
CXXCatchStmt: 32		|	CXXCatchStmt: 24
CXXForRangeStmt: 72		|	CXXForRangeStmt: 64
ObjCAtFinallyStmt: 24		|	ObjCAtFinallyStmt: 16
ObjCAtSynchronizedStmt: 32	|	ObjCAtSynchronizedStmt: 24
ObjCAtThrowStmt: 24		|	ObjCAtThrowStmt: 16
ObjCAutoreleasePoolStmt: 24	|	ObjCAutoreleasePoolStmt: 16
llvm-svn: 233921

Patch by Douglas Katzman

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

llvm-svn: 233920

This is a tool for checking consistency of code generation with different
compiler options (such as -g or outputting to .s). This tool has found a number
of code generation issues. The script acts as a wrapper to clang or clang++
performing 2 (or more) compiles then comparing the object files. Instructions
for use are in check_cfc.py including how to use with LNT.

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

llvm-svn: 233919

llvm-svn: 233918

This works around a bug (PR56859) that is fixed in all versions of GCC I tested
with but was present in 4.8.0. Using 4.8.0 is of course a terrible idea, but looks
like we can't drop it just yet.

llvm-svn: 233916

Replace some unsafe API calls with safe alternatives on Windows, prepare code for similar actions on other platforms - wrap unsafe API calls into macros.

llvm-svn: 233915

Eliminated the write to depth field of the machine_hierarchy data structure in __kmp_get_hierarchy(), thus fixing race condition. Now local variable used by each thread.

llvm-svn: 233914

llvm-svn: 233913

MSVC 2013 can't even parse __declspec(align(sizeof(foo))). We'll have to
wait until MSVC 2015 for this.

This partially reverts commit r233911.

llvm-svn: 233912

This isn't perfect as it still assumes sizeof(void*) == alignof(void*),
but we can fix that when compiler support gets better.

Shrinks some Stmts that happen to inherit from Stmt and have a
SourceLocation as the first member (64 bit archs only).

llvm-svn: 233911

We wrap __attribute((aligned)) for GCC 4.7 and __declspec(align) for
MSVC. The latter behaves weird in some contexts so this should be used
carefully.

llvm-svn: 233910

Summary:
Avoid duplicate code in Mips16FrameLowering and MipsSEFrameLowering by
providing an implementation of the eliminateCallFramePseudoInstr()
function from their base class.

Depends on D8640.

Reviewers: dsanders

Subscribers: llvm-commits

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

llvm-svn: 233909

Differential revision: http://reviews.llvm.org/D8765

llvm-svn: 233908

These test cases check if they are able to read registers after the
inferior is crashed. Previously they did it with reading the eax
register what is only available on i386 and x86_64. Thic CL add code to
do the check based on the target architecture (currently i386, x86_64
and aarch64 is supported)

Differential revision: http://reviews.llvm.org/D8702

llvm-svn: 233907

by Asaf Badouh (asaf.badouh@intel.com)

llvm-svn: 233906

Summary:
adjustStackPtr() is implemented from both MipsSEInstrInfo and
Mips16InstrInfo. It makes sense to expose this function from
MipsInstrInfo and avoid explicit casting in some cases.

Depends on D8638.

Reviewers: dsanders

Subscribers: llvm-commits

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

llvm-svn: 233905

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: llvm-commits

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

llvm-svn: 233904

Corrected forgotten change to remove excess "generic-armv8.1-a" cpu

Subscribers: llvm-commits

Completion of http://reviews.llvm.org/rL233811

llvm-svn: 233903

llvm-svn: 233902

Since we no longer support MSVC 2012, we can assume that variadic
templates are always supported. This patch removes an #ifdef for
C++ compilers that don't support variadic templates.

llvm-svn: 233901

The function call that goes through PLT table may be performed
from both ARM and Thumb code.
This situation requires adding a veneer to original PLT code
(which is always ARM) to effect Thumb-to-ARM transition.

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

llvm-svn: 233900