[AArch64] Disable complex GEP optimization by default.

Enough concerns were raised that this optimization is pessimising some code patterns.

The obvious fix, to add a Reassociate run afterwards, causes even more pessimisation in some cases due to fewer complex addressing modes being matched. As there isn't a trivial fix for this, backing this out by default until someone gets a chance to fix the addressing mode matcher.

llvm-svn: 235491

Have more strict type checks when creating BinOp nodes in BitcodeReader

Summary: Bug found with AFL.

Reviewers: rafael, bkramer

Subscribers: llvm-commits

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

llvm-svn: 235489

[Mips] Assign .MIPS.options section to the PT_LOAD segment

llvm-svn: 235488

[ELF] Allow TargetLayout descendants to control assignment sections to segments

The TargetLayout class puts two sections into the same segment if they
have equal segment types and the same section flags (SHF_xxx). To be
able to merge some sort of sections into the same segment we drop some
flags before comparison. For example to merge string sections into Data
segment we drop SHF_STRINGS and SHF_MERGE flags.

The patch allows TargetLayout descendants to drop some target specific
section flags. MIPS target needs that to merge .MIPS.options section
which has SHF_MIPS_NOSTRIP flag into the LOAD segment.

http://reviews.llvm.org/D9160

llvm-svn: 235487

[ARM] Implement veneers for dynamic executable linking

llvm-svn: 235486

[ARM] Move veneer generators to base class. NFC

llvm-svn: 235485

[ARM] Rename static veneer atoms to absolute code veneer atoms

No functional changes.

llvm-svn: 235484

[patchpoint] Add support for symbolic patchpoint targets to SelectionDAG and the
X86 backend.

The code generated for symbolic targets is identical to the code generated for
constant targets, except that a relocation is emitted to fix up the actual
target address at link-time. This allows IR and object files containing
patchpoints to be cached across JIT-invocations where the target address may
change.

llvm-svn: 235483

[TableGen] Use range based for loops.

llvm-svn: 235482

[TableGen] Remove some deletes that violate ownership semantics. These don't seem to execute in our codebase today and date back to a time when there was an allocation in this function.

llvm-svn: 235481

Revert r235219, it's not needed after r235450.

llvm-svn: 235480

Replace std::auto_ptr with std::unique_ptr

std::auto_ptr is deprecated in GCC 5.0, and we are already using
std::unique_ptr all over the place.

Patch by Xan López.

llvm-svn: 235479

Fix up Exception demo from recent opaque pointer type changes to GEP

llvm-svn: 235478

[TableGen] Make BitRecTy::baseClassOf return true when RHS is an IntRecTy.

Previously the code was accidentally checking if 'this' was an IntRecTy which it can't be since 'this' is a BitRecTy. Looking back at the history it appears it was intended to check RHS.

llvm-svn: 235477

Don't use 'nullptr' in comment. Just use 'null'.

llvm-svn: 235476

[opaque pointer types] Serialize the value type for atomic store instructions

Without pointee types the space optimization of storing only the pointer
type and not the value type won't be viable - so add the extra type
information that would be missing.

llvm-svn: 235475

[opaque pointer types] Serialize the value type for store instructions

Without pointee types the space optimization of storing only the pointer
type and not the value type won't be viable - so add the extra type
information that would be missing.

Storeatomic coming soon.

llvm-svn: 235474

Linker: Add flag to override linkage rules

Add a flag to lib/Linker (and `llvm-link`) to override linkage rules.
When set, the functions in the source module *always* replace those in
the destination module.

The `llvm-link` option is `-override=abc.ll`.  All the "regular" modules
are loaded and linked first, followed by the `-override` modules.  This
is useful for debugging workflows where some subset of the module (e.g.,
a single function) is extracted into a separate file where it's
optimized differently, before being merged back in.

Patch by Luqman Aden!

llvm-svn: 235473

llvm-link: Factor out loop over input files, NFC

Factor the loop for linking input files together into a combined module
into a separate function.  This is in preparation for an upcoming patch
that runs the logic twice.

Patch by Luqman Aden!

llvm-svn: 235472

Don't dllimport/export class members with internal linkage (PR23308)

For example, a function taking a parameter with internal linkage will
itself have internal linkage since it cannot be called outside the
translation unit.

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

llvm-svn: 235471

Wrap to 80 columns, fix typo in comment. No behavior change.

llvm-svn: 235470

Revert "[TableGen] Use cast instead of dyn_cast where result isn't checked before being dereferenced."

Turns out I misread the parentheses. Though I'm pretty sure its always a RecordRecTy and non of the callers really seem to expect null. But until I'm completely sure I'm going to revert this.

llvm-svn: 235469

Fix stale comment that mentioned 0 instead of nullptr. NFC.

llvm-svn: 235468

[TableGen] Remove Pool helper class and just use unique_ptr in the maps.

llvm-svn: 235467

[TableGen] Use StringRecTy::get() instead of allocating (and leaking) a StringRecTy object.

llvm-svn: 235466

[TableGen] Use 'isa' to identify UnsetInits rather than comparing with the singleton object created by UnsetInit::get(). Makes it more consistent with the other types.

llvm-svn: 235465

[modules] Cope with partial module macro information, fix memory leak found by buildbot.

llvm-svn: 235464

[TableGen] Use cast instead of dyn_cast where result isn't checked before being dereferenced.

llvm-svn: 235463

Cleanup formatting for consistency with surrounding code.

llvm-svn: 235462

[modules] Build a DAG of module macros for each identifier.

This graph will be used to determine the current set of active macros. This is
foundation work for getting macro visibility correct across submodules of the
current module. No functionality change for now.

llvm-svn: 235461

[x86] allow 64-bit extracted vector element integer stores on a 32-bit system

With SSE2, we can generate a 'movq' or other 64-bit store op on a 32-bit system
even though 64-bit integers are not legal types.

So instead of producing this:

  pshufd $229, %xmm0, %xmm1      ## xmm1 = xmm0[1,1,2,3]
  movd %xmm0, (%eax)
  movd %xmm1, 4(%eax)

We can do:

  movq %xmm0, (%eax)

This is a fix for the problem noted in D7296.

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

llvm-svn: 235460

[WinEH] Correctly handle inlined __finally blocks with captures

We should also teach the inliner to collapse framerecover of
frameaddress of the current frame down to an alloca, but that can happen
later.

llvm-svn: 235459

[opaque pointer type] Avoid using PointerType::getElementType for a few cases of CallInst

Calls to llvm::Value::mutateType are becoming extra-sensitive now that
instructions have extra type information that will not be derived from
operands or result type (alloca, gep, load, call/invoke, etc... ). The
special-handling for mutateType will get more complicated as this work
continues - it might be worth making mutateType virtual & pushing the
complexity down into the classes that need special handling. But with
only two significant uses of mutateType (vectorization and linking) this
seems OK for now.

Totally open to ideas/suggestions/improvements, of course.

With this, and a bunch of exceptions, we can roundtrip an indirect call
site through bitcode and IR. (a direct call site is actually trickier...
I haven't figured out how to deal with the IR deserializer's lazy
construction of Function/GlobalVariable decl's based on the type of the
entity which means looking through the "pointer to T" type referring to
the global)

llvm-svn: 235458

Remove a zero-length file of llvm/test/Transforms/InstCombine/descale-zero.ll.

llvm-svn: 235457

Expose -fdiagnostics-parseable-fixits to clang-cl

Patch by Daniel Cheng!

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

llvm-svn: 235456

Limiting gep merging to fix the performance problem described in
https://llvm.org/bugs/show_bug.cgi?id=23163.

Gep merging sometimes behaves like a reverse CSE/LICM optimization,
which has negative impact on performance. In this patch we restrict
gep merging to happen only when the indexes to be merged are both consts,
which ensures such merge is always beneficial.

The patch makes gep merging only happen in very restrictive cases.
It is possible that some analysis/optimization passes rely on the merged
geps to get better result, and we havn't notice them yet. We will be ready
to further improve it once we see the cases.

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

llvm-svn: 235455

Same issue as in D8685 but for i386.

llvm-svn: 235454

Revert r235451 since it is attached to a wrong Differential Revision. Sorry.

llvm-svn: 235453

[cuda] Allow using integral non-type template parameters as launch_bounds attribute arguments.

 - Changed CUDALaunchBounds arguments from integers to Expr* so they can
   be saved in AST for instantiation.
 - Added support for template instantiation of launch_bounds attrubute.
 - Moved evaluation of launch_bounds arguments to NVPTXTargetCodeGenInfo::
   SetTargetAttributes() where it can be done after template instantiation.
 - Added a warning on negative launch_bounds arguments.
 - Amended test cases.

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

llvm-svn: 235452

Limiting gep merging to fix the performance problem described in
https://llvm.org/bugs/show_bug.cgi?id=23163.

Gep merging sometimes behaves like a reverse CSE/LICM optimizations,
which has negative impact on performance. In this patch we restrict
gep merging to happen only when the indexes to be merged are both consts,
which ensures such merge is always beneficial.

The patch makes gep merging only happen in very restrictive cases.
It is possible that some analysis/optimization passes rely on the merged
geps to get better result, and we havn't notice them yet. We will be ready
to further improve it once we see the cases.

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

llvm-svn: 235451

Silence MSVC build alignment warnings

llvm-svn: 235450

[cuda] Added support for CUDA built-in variables.

Added cuda_builtin_vars.h which implements built-in CUDA variables
using __declattr(property).

Fields of built-in variables (except for warpSize) are implemented
using __declattr(property) which replaces read/write of a member field
with a call to a getter/setter member function, in this case with
appropriate NVPTX builtin.

Added a test case to check diagnostics on attempt to construct or
improperly access a built-in variable.

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

llvm-svn: 235448

Add properties to SBExecutionContext to access the several entities it stores in a more Pythonic fashion

llvm-svn: 235447

[modules] Move list of exported module macros from IdentifierInfo lookup table to separate storage, adjacent to the macro directive history.

This is substantially simpler, provides better space usage accounting in bcanalyzer,
and gives a more compact representation. No functionality change intended.

llvm-svn: 235420

[MemCpyOpt] Use the raw i8* dest when optimizing memset+memcpy.

MemIntrinsic::getDest() looks through pointer casts, and using it
directly when building the new GEP+memset results in stuff like:

  %0 = getelementptr i64* %p, i32 16
  %1 = bitcast i64* %0 to i8*
  call ..memset(i8* %1, ...)

instead of the correct:

  %0 = bitcast i64* %p to i8*
  %1 = getelementptr i8* %0, i32 16
  call ..memset(i8* %1, ...)

Instead, use getRawDest, which just gives you the i8* value.
While there, use the memcpy's dest, as it's live anyway.

In most cases, when the optimization triggers, the memset and memcpy
sizes are the same, so the built memset is 0-sized and eliminated.
The problem occurs when they're different.

Fixes a regression caused by r235232: PR23300.

llvm-svn: 235419

[Hexagon] Patterns for frame index with offset for isel

llvm-svn: 235418

Update comment. NFC.

llvm-svn: 235417

Revamp PredIteratorCache interface to be cleaner.

Summary:
This lets us use range based for loops.

Reviewers: chandlerc

Subscribers: llvm-commits

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

llvm-svn: 235416

[NVPTX] do not run DCE after SLSR and SeparateConstOffsetFromGEP

Summary:
With D9096 and D9101, there's no need to run DCE after SLSR and
SeparateConstOffsetFromGEP.

Test Plan: no regression

Reviewers: jholewinski, meheff

Subscribers: jholewinski, llvm-commits

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

llvm-svn: 235415

[LSR][NFC] Remove a stale comment.

The comment was made stale in r171735.

llvm-svn: 235414

DebugInfo: Remove DIArray and DITypeArray typedefs

Remove the `DIArray` and `DITypeArray` typedefs, preferring the
underlying types (`DebugNodeArray` and `MDTypeRefArray`, respectively).

llvm-svn: 235413

DebugInfo: Prepare for removal of DIArray and DITypeArray typedefs

An upcoming LLVM commit will remove the `DIArray` and `DITypeArray`
typedefs that shadow `DebugNodeArray` and `MDTypeRefArray`,
respectively.  Use those types directly.

llvm-svn: 235412

[sanitizer] Plug a memory leak in symbolization code.

llvm-svn: 235411

[SLSR] garbage-collect unused instructions

Summary:
After we rewrite a candidate, the instructions used by the old form may
become unused. This patch cleans up these unused instructions so that we
needn't run DCE after SLSR.

Test Plan: removed -dce in all the SLSR tests

Reviewers: broune, meheff

Subscribers: llvm-commits

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

llvm-svn: 235410

[SeparateConstOffsetFromGEP] garbage-collect intermediate instructions

Summary: so that we needn't run DCE after this pass.

Test Plan: removed -dce from the commandline in split-gep.ll and split-gep-and-gvn.ll

Reviewers: meheff

Subscribers: llvm-commits, HaoLiu, hfinkel, jholewinski

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

llvm-svn: 235409

Remove FilesToRemove->push_back(Filename) from sys::DontRemoveFileOnSignal.

llvm-svn: 235408

DebugInfo: Use MDType in DITypeIdentifierMap

Use `MDType*` instead of `MDNode*` in `DITypeIdentifierMap`, since all
the members should be types.

llvm-svn: 235407

Move IDF Calculation to a separate file, expose an interface to it.

Summary:
MemorySSA uses this algorithm as well, and this enables us to reuse the code in both places.

There are no actual algorithm or datastructure changes in here, just code movement.

Reviewers: qcolombet, chandlerc

Subscribers: llvm-commits

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

llvm-svn: 235406

DebugInfo: Prune unnecessary forward declarations

Probably these forward declarations were once useful, but they certainly
don't belong here now.

llvm-svn: 235405

DebugInfo: Drop rest of DIDescriptor subclasses

Delete the remaining subclasses of (the already deleted) `DIDescriptor`.
Part of PR23080.

llvm-svn: 235404

DebugInfo: Prepare for deletion of DIDescriptor subclasses

An upcoming LLVM commit will delete all the remaining subclasses of (the
already deleted) `DIDescriptor`.  Stop using them.

llvm-svn: 235403

Recommend to use CMake on the Clang Getting Started page.

llvm-svn: 235402

Revert r235398 "[cuda] Added support for CUDA built-in variables."

r235398 was causing buildbot break due to missing Makefile changes.

llvm-svn: 235401

DebugInfo: Assert dbg.declare/value insts are valid

Remove early returns for when `getVariable()` is null, and just assert
that it never happens.  The Verifier already confirms that there's a
valid variable on these intrinsics, so we should assume the debug info
isn't broken.  I also updated a check for a `!dbg` attachment, which the
Verifier similarly guarantees.

llvm-svn: 235400

Re-land r235154-r235156 under the existing -sehprepare flag

Keep the old SEH fan-in lowering on by default for now, since projects
rely on it.  This will make it easy to test this change with a simple
flag flip.

llvm-svn: 235399

[cuda] Added support for CUDA built-in variables.

Added cuda_builtin_vars.h which implements built-in CUDA variables
using __declattr(property).

Fields of built-in variables (except for warpSize) are implemented
using __declattr(property) which replaces read/write of a member field
with a call to a getter/setter member function, in this case with
appropriate NVPTX builtin.

Added a test case to check diagnostics on attempt to construct or
improperly access a built-in variable.

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

llvm-svn: 235398

Implement target-specific __attribute__((aligned)) value

The GCC construct __attribute__((aligned)) is defined to set alignment
to "the default alignment for the target architecture" according to
the GCC documentation:

  The default alignment is sufficient for all scalar types, but may not be
  enough for all vector types on a target that supports vector operations.
  The default alignment is fixed for a particular target ABI.

clang currently hard-coded an alignment of 16 bytes for that construct,
which is correct on some platforms (including X86), but wrong on others
(including SystemZ).  Since this value is ABI-relevant, it is important
to get correct for compatibility purposes.

This patch adds a new TargetInfo member "DefaultAlignForAttributeAligned"
that targets can set to the appropriate default __attribute__((aligned))
value.

Note that I'm deliberately *not* using the existing "SuitableAlign"
value, which is used to set the pre-defined macro __BIGGEST_ALIGNMENT__,
since those two values may not be the same on all platforms.  In fact,
on X86, __attribute__((aligned)) always uses 16-byte alignment, while
__BIGGEST_ALIGNMENT__ may be larger if AVX-2 or AVX-512 are supported.
(This is actually not yet correctly implemented in clang either.)

The patch provides a value for DefaultAlignForAttributeAligned only for
SystemZ, and leaves the default for all other targets at 16, which means
no visible change in behavior on all other targets.  (The value is still
wrong for some other targets, but I'd prefer to leave it to the target
maintainers for those platforms to fix.)

llvm-svn: 235397

Provide alignment info on LLVM external symbols

Code in CodeGenModule::GetOrCreateLLVMGlobal that sets up GlobalValue
object for LLVM external symbols has this comment:

    // FIXME: This code is overly simple and should be merged with other global
    // handling.

One part does seems to be "overly simple" currently is that this code
never sets any alignment info on the GlobalValue, so that the emitted
IR does not have any align attribute on external globals.  This can
lead to unnecessarily inefficient code generation.

This patch adds a GV->setAlignment call to set alignment info.

llvm-svn: 235396

Fix __alignof__ of global variables on SystemZ

SystemZ prefers to align all global variables to two bytes, which is
implemented by setting the TargetInfo member MinGlobalAlign.

However, for compatibility with existing compilers this should *not*
change the ABI alignment value as retrieved via __alignof__, which
it currently does.

This patch fixes the issue by having ASTContext::getDeclAlign ignore
the MinGlobalAlign setting in the ForAlignof case.

Since SystemZ is the only platform setting MinGlobalAlign, this should
cause no change for any other target.

llvm-svn: 235395

X86: Match for X86ISD nodes in LowerBUILD_VECTOR instead of BUILD_VECTORCombine

There doesn't seem to be a reason to perform this target ISD node matching
in an DAGCombine, moving it to lowering fixes PR23296.

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

llvm-svn: 235394

[ELF] Change return type of the OutputSection::flags() method

This method returns _flags field which has `uint64_t` type. Now the
field's type and the method's return type are consistent.

llvm-svn: 235393

[ELF] Narrow down the type of OutputSection::_sections container

The `OutputSection::appendSection()` method always gets a pointer
to the `Section` class descendants. So it is not necessary to keep them
in the vector of `Chunk` pointers.

No functional changes.

llvm-svn: 235392

[Mips] Write .reginfo section into the separate PT_MIPS_REGINFO segment

llvm-svn: 235391

[ELF] Simplify class memeber function declaration

No functional changes.

llvm-svn: 235390

Minor edits to the llvm-cov documentation.

This just changes a few places to use a slightly more formal style.

llvm-svn: 235389

Placate clang. lldb can build on FreeBSD with -Werror again.

llvm-svn: 235387

s/NULL/nullptr/ in OrcTestCommon.h to silence -Wsentinel in clang-cl

llvm-svn: 235386

AVX-512: Added VPMOVx2M instructions for SKX,
fixed encoding of VPMOVM2x.

llvm-svn: 235385

Remove target triples from test cases

I just learned that target triples prevent test cases to be run on other
architectures. Polly test cases are until now sufficiently target independent
to not require any target triples. Hence, we drop them.

llvm-svn: 235384

AVX-512: Added VPTESTM and VPTESTNM instructions for SKX

llvm-svn: 235383

[mips] [IAS] Implement the .asciiz directive.

Summary:
This directive is exactly the same as .asciz, except it's only used by MIPS.
It is used to store null terminated strings in object files.

Reviewers: rafael, dsanders, echristo

Reviewed By: dsanders, echristo

Subscribers: echristo, llvm-commits

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

llvm-svn: 235382

Fix some formatting issues

llvm-svn: 235381

Rename 'scattering' to 'schedule'

In Polly we used both the term 'scattering' and the term 'schedule' to describe
the execution order of a statement without actually distinguishing between them.
We now uniformly use the term 'schedule' for the execution order.  This
corresponds to the terminology of isl.

History: CLooG introduced the term scattering as the generated code can be used
as a sequential execution order (schedule) or as a parallel dimension
enumerating different threads of execution (placement). In Polly and/or isl the
term placement was never used, but we uniformly refer to an execution order as a
schedule and only later introduce parallelism. When doing so we do not talk
about about specific placement dimensions.

llvm-svn: 235380

[mips][microMIPSr6] Implement CACHE and PREF instructions

Implement CACHE and PREF instructions using mapping.

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

llvm-svn: 235379

Pass an actual schedule to the isl_union_access [NFC]

This change is a step towards using a single isl_schedule object throughout
Polly. At the moment the schedule is just constructed from the flat
isl_union_map that defines the schedule. Later we will obtain it directly
from the scop and potentially obtain a schedule with a non-trivial internal
structure that will allow faster dependence analysis.

llvm-svn: 235378

[mips] Cleanup old floating-point flag conditions definitions. NFC.

Reviewers: dsanders

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

llvm-svn: 235377

[mips] Optimize code generation for 64-bit variable shift instructions.

Summary:
The 64-bit version of the variable shift instructions uses the
shift_rotate_reg class which uses a GPR32Opnd to specify the variable
shift amount. With this patch we avoid the generation of a redundant
SLL instruction for the variable shift instructions in 64-bit targets.

Reviewers: dsanders

Subscribers: llvm-commits

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

llvm-svn: 235376

AVX-512: Added logical and arithmetic instructions for SKX
by Asaf Badouh (asaf.badouh@intel.com)

llvm-svn: 235375

Drop unneccessary -basicaa passes in DependenceInfo test cases

llvm-svn: 235374

Move to isl's new dependence analysis interface [NFC]

isl_union_map_compute_flow() has been replaced by
isl_union_access_info_compute_flow(). This change does not intend to
change funcitonality, yet. However, it will allow us to pass in subsequent
changes schedule trees to the dependence analysis instead of flat schedules.
This should speed up dependence analysis for important cases significantly.

llvm-svn: 235373

[X86][SSE] Provide execution domains for scalar floating point operations

This is an updated version of Chandler's patch D7402 that got accepted but never committed, and has bit-rotted a bit since.

I've updated the execution domain declarations to match the approach of the packed templates and also added some extra scalar unary tests.

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

llvm-svn: 235372

CONCAT_VECTOR of BUILD_VECTOR - minor fix

Fixed issue with the combine of CONCAT_VECTOR of 2 BUILD_VECTOR nodes - the optimisation wasn't ensuring that the scalar operands of both nodes were the same type/size for implicit truncation.

Test case spotted by Patrik Hagglund

llvm-svn: 235371

Fix generic shift expansion when shift amount is 0

Summary:
This fixes http://llvm.org/bugs/show_bug.cgi?id=16439.

This is one possible way to approach this. The other would be to split InL>>(nbits-Amt) into (InL>>(nbits-1-Amt))>>1, which is also valid since since we only need to care about Amt up nbits-1. It's hard to tell which one is better since the shift might be expensive if this stage of expansion is not yet a legal machine integer, whereas comparisons with zero are relatively cheap at all sizes, but more expensive than a shift if the shift is on a legal machine type.

Patch by Keno Fischer!

Test Plan: regression test from http://reviews.llvm.org/D7752

Reviewers: chfast, resistor

Reviewed By: chfast, resistor

Subscribers: sanjoy, resistor, chfast, llvm-commits

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

llvm-svn: 235370

Enhanced vim support.

This brings the utils/vim folder into a more vim-like format by moving
the syntax hightlighting files into a syntax subdirectory. It adds
some minimal settings that everyone should agree on to ftdetect/ftplugin and
features a new indentation plugin for .ll files.

llvm-svn: 235369

XFAIL tests that are failed on linux with gcc-4.9.2

Summary:
- add decorator functions to xfail and skip test on specific os, architecture and version of comipler
- xfail failing test with gcc-4.9.2 on linux
- add one usage of skipIf function

Test Plan:
Run tests with different archs, and version of compilers to verify decorator function working as expected
Run tests with gcc-4.9.2 and no failure reported

Reviewers: sivachandra, ovyalov, vharron, chaoren

Subscribers: lldb-commits

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

llvm-svn: 235368

X86: Do not select X86 custom vector nodes if operand types don't match

X86ISD::ADDSUB, X86ISD::(F)HADD, X86ISD::(F)HSUB should not be selected
if the operand types do not match the result type because vector type
legalization cannot deal with this for custom nodes.

Testcase X86ISD::ADDSUB is attached. I could not create a testcase for
the FHADD/FHSUB cases because of: https://llvm.org/bugs/show_bug.cgi?id=23296

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

llvm-svn: 235367

Tighten bundling section alignment test.

Leftover comment from http://reviews.llvm.org/D9131

llvm-svn: 235366

[MC] When using bundle aligment, align sections to bundle size

Summary:
Bundle aligment requires that the functions always start at an aligned address.
Usually this is ensured by the compiler, but assembly code does not always
begin with a .align directive.

This change ensures that sections get the correct alignment if they contain
any instructions and bundling is enabled. (It also makes LLVM match the
behavior of GNU as).

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

llvm-svn: 235365

InstCombine: fold (sitofp (zext x)) to (uitofp x)

This is okay because the zext guarantees the high bit is zero,
and so the value is unsigned.

llvm-svn: 235364

Fix flakiness in fp16-promote.ll

Summary:
In the f16-promote test, make the checks for native conversion instructions
similar to the libcall checks:
- Remove hard coded register names
- Do not check exact instruction sequences.

This fixes test flakiness due to non-determinism in instruction
scheduling and register allocation.  I also fixed a few minor things in
the CHECK-LIBCALL checks.

I'll try to find a way to check that unnecessary loads, stores, or
conversions don't happen.

Reviewers: mzolotukhin, srhines, ab

Subscribers: llvm-commits

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

llvm-svn: 235363