R600: Move MIN/MAX matching from LowerOperation() to PerformDAGCombine()

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208429 91177308-0d34-0410-b5e6-96231b3b80d8

Attempt to pacify the bots - this commit requires asserts.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208424 91177308-0d34-0410-b5e6-96231b3b80d8

Use auto and clang-format this snippet.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208421 91177308-0d34-0410-b5e6-96231b3b80d8

Run clang-format in small sections of code to make a patch easier to read.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208419 91177308-0d34-0410-b5e6-96231b3b80d8

Delete trailing whitespace.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208416 91177308-0d34-0410-b5e6-96231b3b80d8

Delete trailing white space.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208415 91177308-0d34-0410-b5e6-96231b3b80d8

[mips] Marked up instructions added in MIPS-IV and tested that IAS for -mcpu=mips[123] does not accept them

Summary:
This required a new instruction group representing the 32-bit subset of
MIPS-IV that was available in MIPS32

A small number of instructions are correctly rejected but with the wrong error
message. These have been placed in a separate test for now.

Depends on D3676

Reviewers: vmedic

Reviewed By: vmedic

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208414 91177308-0d34-0410-b5e6-96231b3b80d8

ARM: HFAs must be passed in consecutive registers

When using the ARM AAPCS, HFAs (Homogeneous Floating-point Aggregates) must
be passed in a block of consecutive floating-point registers, or on the stack.
This means that unused floating-point registers cannot be back-filled with
part of an HFA, however this can currently happen. This patch, along with the
corresponding clang patch (http://reviews.llvm.org/D3083) prevents this.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208413 91177308-0d34-0410-b5e6-96231b3b80d8

[yaml2obj] Follow-up to the r208228 and r208406. Remove duplicated YAML
map keys.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208412 91177308-0d34-0410-b5e6-96231b3b80d8

Remove trailing white space.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208411 91177308-0d34-0410-b5e6-96231b3b80d8

[mips] Remove unused CondMov feature bit

Summary:
No functional change

Depends on D3675

Reviewers: vmedic

Reviewed By: vmedic

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208410 91177308-0d34-0410-b5e6-96231b3b80d8

[mips] Marked up instructions added in MIPS-III and tested that IAS for -mcpu=mips[12] does not accept them

Summary:
This required a new instruction group representing the 32-bit subset of
MIPS-III that was available in MIPS32

A small number of instructions are correctly rejected but with the wrong error
message. These have been placed in a separate test for now.

There's some obvious InstAlias's that ought to be marked MIPS-III but arent.
This is because they are not currently tested. I intend to catch these with
a final pass through the tablegen records to find tablegen records without
ISA annotations.

Depends on D3674

Reviewers: vmedic

Reviewed By: vmedic

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208408 91177308-0d34-0410-b5e6-96231b3b80d8

Mark yaml2obj-elf-x86-rel.yaml as XFAIL:vg_leak for now. This has two pairs of duplicate hashes.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208406 91177308-0d34-0410-b5e6-96231b3b80d8

Fix 80 col violation.
No functional change intended.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208405 91177308-0d34-0410-b5e6-96231b3b80d8

[asan] Stop leaking X86Operands.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208400 91177308-0d34-0410-b5e6-96231b3b80d8

[mips][mips64r6] Add experimental support for MIPS32r6 and MIPS64r6

Summary:
Adds MIPS32r6/MIPS64r6 and checks the compatibility requirements for these
processors.

I've also included comments to describe removed and re-encoded instructions,
along with placeholder def's for the new instructions but there are no
functional changes to codegen at this point.

Reviewers: jkolek, vmedic

Reviewed By: vmedic

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208399 91177308-0d34-0410-b5e6-96231b3b80d8

[mips] Added missing daddu test to the valid instruction tests.

Summary: Depends on D3673

Reviewers: vmedic

Reviewed By: vmedic

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208398 91177308-0d34-0410-b5e6-96231b3b80d8

[mips] Added missing dsra -> dsrav and sra -> srav aliases.

Summary: dsll, dsrl, sll, and srl already exist.

Reviewers: vmedic

Reviewed By: vmedic

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208397 91177308-0d34-0410-b5e6-96231b3b80d8

MemoryBuffer: don't force mmap when stat fails

Fix error handling introduced in r127426 that could result in MemoryBuffers not
having null termination.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208396 91177308-0d34-0410-b5e6-96231b3b80d8

MemoryBuffer: remove unusued definitions

These were made redundant back in r186560.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208395 91177308-0d34-0410-b5e6-96231b3b80d8

test/TableGen: Remove XFAIL:vg_leak out of 3 tests corresponding to r208293.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208393 91177308-0d34-0410-b5e6-96231b3b80d8

Don't indent inside a namespace. Don't duplicate a function name in comment.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208389 91177308-0d34-0410-b5e6-96231b3b80d8

Remove use of = default/= delete as they're unsupported on MSVC2012

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208388 91177308-0d34-0410-b5e6-96231b3b80d8

ARM: support PIC on Windows on ARM

Handle lowering of global addresses for PIC mode compilation on Windows.  Always
use the movw/movt load to load the address as Windows on ARM requires ARMv7+ and
is a pure Thumb environment.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208385 91177308-0d34-0410-b5e6-96231b3b80d8

printCustom is only used in PseudoSourceValue, remove it from Value.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208383 91177308-0d34-0410-b5e6-96231b3b80d8

Add missing linkage predicates.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208379 91177308-0d34-0410-b5e6-96231b3b80d8

[RuntimeDyld] Unify the RuntimeDyldMachO resolve.*Relocation method signatures
around RelocationEntries, rather than passing the same information via loose
arguments.

No functional change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208375 91177308-0d34-0410-b5e6-96231b3b80d8

Optimize shufflevector that copies an i64/f64 and zeros the rest.

Summary:
Also ran clang-format on the function. The code added is the last else
if block.

Reviewers: nadav, craig.topper, delena

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208372 91177308-0d34-0410-b5e6-96231b3b80d8

[TargetInstrInfo] Fix the implementation of commuteInstruction to match the
comment of the API.

Relaxes the behavior of TargetInstrInfo::commuteInstruction when
TargetInstrInfo::findCommutedOpIndices returns false.

Previously TargetInstrInfo triggered a fatal error in such situation whereas based
on the comment in the API it should just return nullptr. Indeed the only
precondition that should be ensured is that the instruction must be commutable.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208371 91177308-0d34-0410-b5e6-96231b3b80d8

Improve wording to make it sounds more like a change than an analysis.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208370 91177308-0d34-0410-b5e6-96231b3b80d8

test/CodeGen: Check that the correct register is used in a store

This tightens up r208351 to ensure that a store is fed with the
correct value.

Thanks to Quentin Colombet for spotting this!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208368 91177308-0d34-0410-b5e6-96231b3b80d8

Reapply r207876 (Try simplifying LexicalScopes ownership again) including a workaround for an MSVC2012 bug regarding forward_as_tuple

(r207876 was reverted in r208131 after seeing some consistent buildbot
failure for MSVC 2012. The original commits were in r207724-r207726)

Takumi was nice enough to dig into this and locate this Microsoft
Connect issue:
http://connect.microsoft.com/VisualStudio/feedback/details/814899/forward-as-tuple-debug-implementation-error
describing a bug in MSVC2012's forward_as_tuple implementation.

Since the parameters in this instance are trivial/small, pass them by
value (using make_tuple) instead of perfectly-forwarded tuple of rvalue
references (involving the broken forward_as_tuple). Hopefully this will
satisfy MSVC2012.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208364 91177308-0d34-0410-b5e6-96231b3b80d8

Missed formatting

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208362 91177308-0d34-0410-b5e6-96231b3b80d8

StringMap: Move assignment and move construction.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208361 91177308-0d34-0410-b5e6-96231b3b80d8

StringMap: Replace faux-copyability with faux-movability, which is sufficient.

This behavior was added to support StringMaps of StringMaps, default +
move construction are sufficient for this.

Real move construction support coming soon (& probably copy construction
too).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208360 91177308-0d34-0410-b5e6-96231b3b80d8

StringMap support for move-only values.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208359 91177308-0d34-0410-b5e6-96231b3b80d8

Correct formatting.

Sorry for the commit spam. My clang-format crashed on me and the vim
plugin did not print an error, but instead just left the formatting
untouched.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208358 91177308-0d34-0410-b5e6-96231b3b80d8

Use std::remove_if to remove elements from a vector

Suggested-by: Benjamin Kramer <benny.kra@gmail.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208357 91177308-0d34-0410-b5e6-96231b3b80d8

[InstCombine] Some cleanup in optimization of redundant insertvalue instructions.
And one more test added.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208355 91177308-0d34-0410-b5e6-96231b3b80d8

Use range loops.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208353 91177308-0d34-0410-b5e6-96231b3b80d8

Make a CodeGen test more robust against vector register selection

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208351 91177308-0d34-0410-b5e6-96231b3b80d8

[Hexagon] Add new InstrItinClass to support timing classes.

This patch doesn't introduce any functionality change. Test cases will be
added later when v5 support is added.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208349 91177308-0d34-0410-b5e6-96231b3b80d8

Use for range loops.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208348 91177308-0d34-0410-b5e6-96231b3b80d8

add testcase for r208237: do not collect undef terms

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208347 91177308-0d34-0410-b5e6-96231b3b80d8

Use range loop.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208346 91177308-0d34-0410-b5e6-96231b3b80d8

R600: Promote f64 vector load/stores to i64 for consistency

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208344 91177308-0d34-0410-b5e6-96231b3b80d8

Use a range loop.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208343 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Add target specific combine rules to fold SSE2/AVX2 packed arithmetic shift intrinsics.

This patch teaches the backend how to combine packed SSE2/AVX2 arithmetic shift
intrinsics.

The rules are:
 - Always fold a packed arithmetic shift by zero to its first operand;
 - Convert a packed arithmetic shift intrinsic dag node into a ISD::SRA only if
   the shift count is known to be smaller than the vector element size.

This patch also teaches to function 'getTargetVShiftByConstNode' how fold
target specific vector shifts by zero.

Added two new tests to verify that the DAGCombiner is able to fold
sequences of SSE2/AVX2 packed arithmetic shift calls.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208342 91177308-0d34-0410-b5e6-96231b3b80d8

test: fix test on Windows

When building on Windows, the default target is Windows.  Windows on ARM does
not support ARM mode compilation, resulting in test failures.  Simply specify a
triple to ensure that we are testing the correct behaviour.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208340 91177308-0d34-0410-b5e6-96231b3b80d8

Mark test/TableGen/listconcat.td as XFAIL:vg_leak. llvm-tblgen is ignorant of vg_leak.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208337 91177308-0d34-0410-b5e6-96231b3b80d8

[mips] Add PredicateControl to InstAlias's

Summary:
No functional change

Depends on D3649

Reviewers: vmedic

Reviewed By: vmedic

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208334 91177308-0d34-0410-b5e6-96231b3b80d8

[ARM64] Add diagnostics for expected arithmetic shifts

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208330 91177308-0d34-0410-b5e6-96231b3b80d8

[ARM64] Re-work parsing of ADD/SUB shifted immediate operands

The parsing of ADD/SUB shifted immediates needs to be done explicitly so
that better diagnostics can be emitted, as a side effect this also
removes some of the hacks in the current method of handling this operand
type.

Additionally remove manual CMP aliasing to ADD/SUB and use InstAlias
instead.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208329 91177308-0d34-0410-b5e6-96231b3b80d8

[mips] Correct tests that are meant to test valid assembly. They were actually rejected by GAS.

Summary:
I've noticed a bug in my test generator script that caused 64-bit objects
to be disassembled as if it were using the O32 ABI, giving the wrong register
names. As a result, it generated assembly files that are rejected by GAS when
assembling for the correct ABI. This was caused by the generator setting the
ELF e_flags incorrectly before disassembling the object.

This patch corrects the invalid tests that have already been committed by
replacing the ABI-dependent register names with numeric registers. In addition
to fixing the tests this allows the 32-bit and 64-bit ISA tests to be easily diffed
to produce the invalid-*.s tests which test that instructions defined in later ISA's
are not accepted.

Depends on D3648

Reviewers: vmedic

Reviewed By: vmedic

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208327 91177308-0d34-0410-b5e6-96231b3b80d8

[ARM64] Ensure immediates in extend operands are in a valid range

Also emit a more useful diagnostic when they are not.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208318 91177308-0d34-0410-b5e6-96231b3b80d8

[ARM64] Check for proper immediate in shift/extend operands

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208317 91177308-0d34-0410-b5e6-96231b3b80d8

ARM big endian function argument passing

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208316 91177308-0d34-0410-b5e6-96231b3b80d8

Fix a spelling error

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208314 91177308-0d34-0410-b5e6-96231b3b80d8

[mips] Implement l[wd]c3, and s[wd]c3.

Summary:
These instructions were added in MIPS-I, and MIPS-II but were removed in
MIPS-III. Interestingly, GAS continues to accept them when assembling for
MIPS-III.

For the moment, these instructions will follow GAS and accept them for
MIPS-III and newer but this will be tightened up when the invalid-*.s
tests are added.

Depends on D3647

Reviewers: vmedic

Reviewed By: vmedic

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208311 91177308-0d34-0410-b5e6-96231b3b80d8

Add isOSFreeBSD triple test

For http://reviews.llvm.org/D3448

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208309 91177308-0d34-0410-b5e6-96231b3b80d8

Revert test commit. Removed blank line.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208308 91177308-0d34-0410-b5e6-96231b3b80d8

[ARM64-BE] Teach fast-isel about how to set up sub-word stack arguments for big endian calls.

SelectionDAG already knows about this, but fast-isel was ignorant.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208307 91177308-0d34-0410-b5e6-96231b3b80d8

[mips] Marked up instructions added in MIPS-II and tested that IAS for -mcpu=mips1 does not accept them

Summary:
A small number of instructions are rejected with the wrong error message.
These have been placed in a separate test for now. There seems to be some
parsing quirk that triggers when these instructions are disabled.

Depends on D3571

Reviewers: vmedic

Reviewed By: vmedic

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208305 91177308-0d34-0410-b5e6-96231b3b80d8

[mips] Implement tlbp, tlbr, tlbwi, and tlbwr

Reviewers: vmedic, dsanders

Reviewed By: dsanders

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208301 91177308-0d34-0410-b5e6-96231b3b80d8

Test commit. Added blank line.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208298 91177308-0d34-0410-b5e6-96231b3b80d8

ARM64: make sure FastISel emits SSA MachineInstrs

We need to use a temporary register for a 2-step operation like REM.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208297 91177308-0d34-0410-b5e6-96231b3b80d8

[asan] Preserve flags in asm instrumentation.

Patch by Yuri Gorshenin.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208296 91177308-0d34-0410-b5e6-96231b3b80d8

Use a vector of unique_ptrs to fix a memory leak introduced in r208179.

Also removed an inaccurate comment that stated that a DenseMap was used as
storage for the ListInit*'s. It's currently using a FoldingSet.

I expect there's a better way to fix this but I haven't found it yet. FoldingSet
is incompatible with the Pool template and I'm not sure if FoldingSet can be
safely replaced with a DenseMap of computed FoldingSetID's to ListInit*'s.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208293 91177308-0d34-0410-b5e6-96231b3b80d8

Move late partial-unrolling thresholds into the processor definitions

The old method used by X86TTI to determine partial-unrolling thresholds was
messy (because it worked by testing target features), and also would not
correctly identify the target CPU if certain target features were disabled.
After some discussions on IRC with Chandler et al., it was decided that the
processor scheduling models were the right containers for this information
(because it is often tied to special uop dispatch-buffer sizes).

This does represent a small functionality change:
 - For generic x86-64 (which uses the SB model and, thus, will get some
   unrolling).
 - For AMD cores (because they still currently use the SB scheduling model)
 - For Haswell (based on benchmarking by Louis Gerbarg, it was decided to bump
   the default threshold to 50; we're working on a test case for this).
Otherwise, nothing has changed for any other targets. The logic, however, has
been moved into BasicTTI, so other targets may now also opt-in to this
functionality simply by setting LoopMicroOpBufferSize in their processor
model definitions.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208289 91177308-0d34-0410-b5e6-96231b3b80d8

Revert "SCEV: Use I = vector<>.erase(I) to iterate and delete at the same time"

as committed in r208282. The original commit was incorrect.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208286 91177308-0d34-0410-b5e6-96231b3b80d8

AArch64/ARM64: Port NEON post-increment load/store with 2/3/4 vectors to ARM64 backend.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208284 91177308-0d34-0410-b5e6-96231b3b80d8

SCEV: Use I = vector<>.erase(I) to iterate and delete at the same time

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208282 91177308-0d34-0410-b5e6-96231b3b80d8

[modules] Add missing #include.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208276 91177308-0d34-0410-b5e6-96231b3b80d8

test: fix silly typo

Oh silly Darwin and your case insensitive file system.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208274 91177308-0d34-0410-b5e6-96231b3b80d8

ARM: support FK_SecRel_2 relocations on WoA

This adds FK_SecRel_2 relocation support to ARM.  This enables the building of
object files for armv7-windows-msvc which enables CodeView line tables for
debugging as opposed to armv7-windows-itanium which currently uses DWARF.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208273 91177308-0d34-0410-b5e6-96231b3b80d8

Simplify and fix incorrect comment. No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208272 91177308-0d34-0410-b5e6-96231b3b80d8

Lower certain build_vectors to insertps instructions

Summary:
Vectors built with zeros and elements in the same order as another
(source) vector are optimized to be built using a single insertps
instruction.
Also optimize when we move one element in a vector to a different place
in that vector while zeroing out some of the other elements.

Further optimizations are possible, described in TODO comments.
I will be implementing at least some of them in the near future.

Added some tests for different cases where this optimization triggers.

Reviewers: nadav, delena, craig.topper

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208271 91177308-0d34-0410-b5e6-96231b3b80d8

Back out r208257 while I investigate tester failures.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208267 91177308-0d34-0410-b5e6-96231b3b80d8

GlobalValue: Assert symbols with local linkage have default visibility

The change to ExtractGV.cpp has no functionality change except to avoid
the asserts.  Existing testcases already cover this, so I didn't add a
new one.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208264 91177308-0d34-0410-b5e6-96231b3b80d8

IR: Don't allow non-default visibility on local linkage

Visibilities of `hidden` and `protected` are meaningless for symbols
with local linkage.

  - Change the assembler to reject non-default visibility on symbols
    with local linkage.

  - Change the bitcode reader to auto-upgrade `hidden` and `protected`
    to `default` when the linkage is local.

  - Update LangRef.

<rdar://problem/16141113>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208263 91177308-0d34-0410-b5e6-96231b3b80d8

LTO: Assert visibility of local linkage when merging symbols

`ModuleLinker::getLinkageResult()` shouldn't create symbols with local
linkage and non-default visibility -- in fact, symbols with local
linkage shouldn't be merged at all.  Assert to that effect.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208262 91177308-0d34-0410-b5e6-96231b3b80d8

LTO: Check local linkage first

Since visibility is meaningless for symbols with local linkage, check
local linkage before visibility when setting symbol attributes.

When linkage is `internal` and the visibility is `hidden`, the exposed
attribute is now `LTO_SYMBOL_SCOPE_INTERNAL` instead of
`LTO_SYMBOL_SCOPE_HIDDEN`.  Although the bitfield allows *both* to be
specified, the combination is nonsense anyway.

Given changes (in progress) to drop visibility when a symbol has local
linkage, this almost has no functionality change: it's mostly a cleanup
to clarify the logic.

The exception is when something has `appending` linkage.  Before this
change, such symbols would be advertised as `LTO_SYMBOL_SCOPE_INTERNAL`;
now, they'll be given `LTO_SYMBOL_SCOPE_COMMON`.

Unfortunately this is really awkward to test.  This only changes what we
advertise to linkers (before running LTO), not what the final object
looks like.  In theory I could add `DEBUG` output to `llvm-lto` (and
test with "REQUIRES: asserts"), but follow-up commits to disallow
`internal hidden` simplify this anyway.

<rdar://problem/16141113>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208261 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Add a test case for r208252.
Prior to r208252, the FMA 231 family was marked as isCommutable. However the
memory variants of this family are not commutable. Therefore, we did not
implemented the findCommutedOpIndices for those variants and missed that
the default implementation (more or less: commute indices 1 and 2) was
firing behind our back.
As a result, as demonstrated in the test case before the fix, we were
transforming a = b * c + a into a = a * c + b.

I.e., before r208252 we were generating for this test case:
vmovaps %xmm0, %xmm1
vmoss (%rsi), %xmm0
vfmadd231ss (%rdi), %xmm1, %xmm0

Instead of:
vmoss (%rsi), %xmm1
vfmadd231ss (%rdi), %xmm1, %xmm0

<rdar://problem/16800495>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208260 91177308-0d34-0410-b5e6-96231b3b80d8

[RuntimeDyld] Make RuntimeDyldImpl::resolveExternalSymbols preserve the
relocation entries it applies.

Prior to this patch, RuntimeDyldImpl::resolveExternalSymbols discarded
relocations for external symbols once they had been applied. This causes issues
if the client calls MCJIT::finalizeLoadedModules more than once, and updates the
location of any symbols in between (e.g. by calling MCJIT::mapSectionAddress).

No test case yet: None of our in-tree memory managers support moving sections
around. I'll have to hack up a dummy memory manager before I can write a unit
test.

Fixes <rdar://problem/16764378>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208257 91177308-0d34-0410-b5e6-96231b3b80d8

[X86TTI] Remove the unrolling branch limits

The loop stream detector (LSD) on modern Intel cores, which optimizes the
execution of small loops, has limits on the number of taken branches in
addition to uop-count limits (modern AMD cores have similar limits).
Unfortunately, at the IR level, estimating the number of branches that will be
taken is difficult. For one thing, it strongly depends on later passes (block
placement, etc.). The original implementation took a conservative approach and
limited the maximal BB DFS depth of the loop.  However, fairly-extensive
benchmarking by several of us has revealed that this is the wrong approach. In
fact, there are zero known cases where the branch limit prevents a detrimental
unrolling (but plenty of cases where it does prevent beneficial unrolling).

While we could improve the current branch counting logic by incorporating
branch probabilities, this further complication seems unjustified without a
motivating regression. Instead, unless and until a regression appears, the
branch counting will be removed.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208255 91177308-0d34-0410-b5e6-96231b3b80d8

llvm-cov: Fix some funny indentation (NFC)

Noticed by Duncan Exon Smith. Thanks!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208253 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Selectively mark the FMA variants inside a family as isCommutable.
Given a FMA family (e.g., 213, 231), not all the variants (i.e., register or
memory) are commutable.
E.g., for the 213 family (with the syntax src1, src2, src3):
fmaXXX213 A, B, reg3/mem3 == fmaXXX213 B, A, reg3/mem3

Now consider the 231 family:
fmaXXX231 A, B, reg3 == fmaXXX231 A, reg3, B
But
fmaXXX231 A, B, mem3 != fmaXXX231 A, mem3, B
Indeed, mem3 cannot be the second argument of the memory variant of fmaXXX231.

Working on a reduced test case!

<rdar://problem/16800495>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208252 91177308-0d34-0410-b5e6-96231b3b80d8

Reformat a couple of functions for clarity.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208248 91177308-0d34-0410-b5e6-96231b3b80d8

Let OnDiskHashTable call the destructor of its Items.

OnDiskHashTable::insert() calls the Item constructor via placement new, but
nothing called the destructor.  This matters in cases when the Info template
parameter has key_type or data_type typedefs that have a destructor, for
example like IdentifierIndexWriterTrait in clang's GlobalModuleIndex.cpp.

This fixes a 5-year old bug that's been around since the OnDiskHashTable code
was added in r64192.  Bug found by LSan!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208243 91177308-0d34-0410-b5e6-96231b3b80d8

Replace a virtual with an override.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208242 91177308-0d34-0410-b5e6-96231b3b80d8

[Hexagon] Add New TSFlags to be used in the upcoming patches.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208239 91177308-0d34-0410-b5e6-96231b3b80d8

avoid segfaulting

*Quotient and *Remainder don't have to be initialized.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208238 91177308-0d34-0410-b5e6-96231b3b80d8

do not collect undef terms

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208237 91177308-0d34-0410-b5e6-96231b3b80d8

Fix using wrong result type for setcc.

When reducing the bitwidth of a comparison against a constant, the
original setcc's result type was used, which was incorrect.

No test since I don't think any other in tree targets change the
bitwidth of the setcc type depending on the bitwidth of the compared
type.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208236 91177308-0d34-0410-b5e6-96231b3b80d8

Debug.h already includes raw_ostream.h, no need to include it again.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208235 91177308-0d34-0410-b5e6-96231b3b80d8

[Test] Remove c-index-test from the list of substitutions

All the tests are under the clang tests and none should be under llvm moving
forward.

The topic was discussed in this thread:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140428/214905.html

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208234 91177308-0d34-0410-b5e6-96231b3b80d8

split delinearization pass in 3 steps

To compute the dimensions of the array in a unique way, we split the
delinearization analysis in three steps:

- find parametric terms in all memory access functions
- compute the array dimensions from the set of terms
- compute the delinearized access functions for each dimension

The first step is executed on all the memory access functions such that we
gather all the patterns in which an array is accessed. The second step reduces
all this information in a unique description of the sizes of the array. The
third step is delinearizing each memory access function following the common
description of the shape of the array computed in step 2.

This rewrite of the delinearization pass also solves a problem we had with the
previous implementation: because the previous algorithm was by induction on the
structure of the SCEV, it would not correctly recognize the shape of the array
when the memory access was not following the nesting of the loops: for example,
see polly/test/ScopInfo/multidim_only_ivs_3d_reverse.ll

; void foo(long n, long m, long o, double A[n][m][o]) {
;
;   for (long i = 0; i < n; i++)
;     for (long j = 0; j < m; j++)
;       for (long k = 0; k < o; k++)
;         A[i][k][j] = 1.0;

Starting with this patch we no longer delinearize access functions that do not
contain parameters, for example in test/Analysis/DependenceAnalysis/GCD.ll

;;  for (long int i = 0; i < 100; i++)
;;    for (long int j = 0; j < 100; j++) {
;;      A[2*i - 4*j] = i;
;;      *B++ = A[6*i + 8*j];

these accesses will not be delinearized as the upper bound of the loops are
constants, and their access functions do not contain SCEVUnknown parameters.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208232 91177308-0d34-0410-b5e6-96231b3b80d8

[x86] Make the 'x86-64' cpu, what I see as and many use as the generic
default architecture for reasonable modern x86 processors, actually be
modern. This processor model should essentially be "tuned" for modern
x86 chips as much as possible without undue penalties on any specific
architecture. Previously we weren't even using the nice scheduling
models. There are a few other tweaks needed here, but this change at
least I have benchmarked across a decent swatch of chips (intel's
clovertown, westmere, and sandybridge; amd's istanbul) and seen no
significant regressions.

If anyone has suggested ways to test this, just let me know. Somewhat
alarmingly, no existing tests failed.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208230 91177308-0d34-0410-b5e6-96231b3b80d8

Tidy up whitespace with clang-format prior to making significant
changes.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208229 91177308-0d34-0410-b5e6-96231b3b80d8

[yaml2obj] Support ELF x86 relocations.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208228 91177308-0d34-0410-b5e6-96231b3b80d8