llvm-svn: 145458

llvm-svn: 145456

llvm-svn: 145454

tools use. Patch by Simon Atanasyan.

"mips32r1" => "mips32"
"4ke" => mips32r2"
"mips64r1" => "mips64"

llvm-svn: 145451

llvm-svn: 145450

Add another missing pattern. llvm-gcc likes f64 but clang likes i64 so it was generating poor code for some SSE builtins.

llvm-svn: 145448

llvm-svn: 145442

Like V_SET0, these instructions are expanded by ExpandPostRA to xorps /
vxorps so they can participate in execution domain swizzling.

This also makes the AVX variants redundant.

llvm-svn: 145440

Potential bug in RewriteLoopBodyWithConditionConstant: use iterator should not be changed inside the uses enumeration loop.

llvm-svn: 145432

attempt.  

llvm-svn: 145425

llvm-svn: 145422

llvm-svn: 145420

weak variable are compiled by different compilers, such as GCC and LLVM, while
LLVM may increase the alignment to the preferred alignment there is no reason to
think that GCC will use anything more than the ABI alignment.  Since it is the
GCC version that might end up in the final program (as the linkage is weak), it
is wrong to increase the alignment of loads from the global up to the preferred
alignment as the alignment might only be the ABI alignment.

Increasing alignment up to the ABI alignment might be OK, but I'm not totally
convinced that it is.  It seems better to just leave the alignment of weak
globals alone.

llvm-svn: 145413

as MC is the only assembler we support.

This splits MS/Windows and GNU/Windows ASM infos into two seperate classes.
While there is currently only one difference, full MS C++ ABI support will
require many more.

llvm-svn: 145409

- getSymbolOffset() renamed as getSymbolFileOffset()
- getSymbolFileOffset(), getSymbolAddress(), getRelocationAddress() returns same result for ELFObjectFile, MachOObjectFile and COFFObjectFile.
- added getRelocationOffset()
- fixed MachOObjectFile::getSymbolSize()
- fixed MachOObjectFile::getSymbolSection()
- fixed MachOObjectFile::getSymbolOffset() for symbols without section data.

llvm-svn: 145408

Added a test.
Thanks Bruno for reviewing the patch.

llvm-svn: 145403

llvm-svn: 145392

Fix issues in shuffle decoding around VPERM* instructions. Fix shuffle decoding for VSHUFPS/D for 256-bit types. Add pattern matching for memory forms of VPERMILPS/VPERMILPD.

llvm-svn: 145390

clang/lib/Driver/Driver.cpp: Don't pass through negative exit status, or parent would be confused.

llvm::sys::Program::Wait(): Suppose 0x8000XXXX and 0xC000XXXX as abnormal exit code and pass it as negative value.

Win32 Exception Handler: Exit with ExceptionCode on an unhandle exception.

llvm-svn: 145389

Fix VINSERTF128/VEXTRACTF128 to be marked as FP instructions. Allow execution dependency fix pass to convert them to their integer equivalents when AVX2 is enabled.

llvm-svn: 145376

Correctly mark VPERM2F128 as being an FP instruction and add execution domain fixing support to convert it to VPERM2I128 for AVX2.

llvm-svn: 145370

MachO doesn't support the protected visibility. Don't default to 'global' here. <rdar://problem/10396775>

llvm-svn: 145368

This reverts r139450, fixes r139453, and adds much needed comments and a
unit test.

llvm-svn: 145367

llvm-svn: 145364

non_lazy_symbol_pointers section (__IMPORT,__pointers). Ignore the 'hidden' part
since that will place it in the wrong section.
<rdar://problem/10443720>

llvm-svn: 145356

Zap some completely ridiculous code.  There's probably a miscompile here, but I don't really want to try to write a testcase involving an invoke returning a pointer to a varargs function...

llvm-svn: 145347

Replaces r145318 with a more targetted fix for the relocation handling.

llvm-svn: 145346

llvm-svn: 145341

 - This fixes some layering violations and matches how we handle the llvm-c lib,
   for example.

llvm-svn: 145338

rdar://10493453

llvm-svn: 145318

llvm-svn: 145316

llvm-svn: 145313

Make SelectionDAG::InferPtrAlignment use llvm::ComputeMaskedBits instead of duplicating the logic for globals.  Make llvm::ComputeMaskedBits handle GlobalVariables slightly more aggressively, to match what InferPtrAlignment knew how to do.

llvm-svn: 145304

Conservatively returns zero when the GV does not specify an alignment nor is it
initialized. Previously it returns ABI alignment for type of the GV. However, if
the type is a "packed" type, then the under-specified alignments is attached to
the load / store instructions. In that case, the alignment of the type cannot be
trusted.
rdar://10464621

llvm-svn: 145300

llvm-svn: 145292

llvm-svn: 145289

than ABI alignment. These are loads / stores from / to "packed" data structures.
Their alignments are intentionally under-specified.

rdar://10301431

llvm-svn: 145273

llvm-svn: 145272

llvm-svn: 145267

llvm-svn: 145263