[x86] Add same itinerary to SYSEXIT64 as SYSEXIT for consistency.

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

[CMake] Introduce cmake_policy(CMP0022) for target_link_libraries(INTERFACE|PRIVATE).

For now, use both keywords, INTERFACE and PRIVATE via the variable,
  - ${cmake_2_8_12_INTERFACE}
  - ${cmake_2_8_12_PRIVATE}

They could be cleaned up when we introduce 2.8.12.

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

[CMake] Use LINK_LIBS instead of target_link_libraries().

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

[x86] Remove some unused instruction format classes.

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

[x86] Simplify disassembler code slightly.

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

[SROA] The original refactoring inspired by the addrspace patch in
D1764, which in turn set off the other refactorings to make
'getSliceAlign()' a sensible thing.

There are two possible inputs to the required alignment of a memory
transfer intrinsic: the alignment constraints of the source and the
destination. If we are *only* introducing a (potentially new) offset
onto one side of the transfer, we don't need to consider the alignment
constraints of the other side. Use this to simplify the logic feeding
into alignment computation for unsplit transfers.

Also, hoist the clamp of the magical zero alignment for these intrinsics
to the more customary one alignment early. This lets several other
conditions melt away.

No functionality changed. There is a further improvement this exposes
which *will* change functionality, but that's arriving in a separate
patch.

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

[SROA] Yet another slight refactoring that simplifies an API in the
rewriting logic: don't pass custom offsets for the adjusted pointer to
the new alloca.

We always passed NewBeginOffset here. Sometimes we spelled it
BeginOffset, but only when they were in fact equal. Whats worse, the API
is set up so that you can't reasonably call it with anything else -- it
assumes that you're passing it an offset relative to the *original*
alloca that happens to fall within the new one. That's the whole point
of NewBeginOffset, it's the clamped beginning offset.

No functionality changed.

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

[SROA] Simplify the computing of alignment: we only ever need the
alignment of the slice being rewritten, not any arbitrary offset.

Every caller is really just trying to compute the alignment for the
whole slice, never for some arbitrary alignment. They are also just
passing a type when they have one to see if we can skip an explicit
alignment in the IR by using the type's alignment. This makes for a much
simpler interface.

Another refactoring inspired by the addrspace patch for SROA, although
only loosely related.

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

[SROA] Use NewOffsetBegin in the unsplit case for memset merely for
consistency with memcpy rewriting, and fix a latent bug in the alignment
management for memset.

The alignment issue is that getAdjustedAllocaPtr is computing the
*relative* offset into the new alloca, but the alignment isn't being set
to the relative offset, it was using the the absolute offset which is
into the old alloca.

I don't think its possible to write a test case that actually reaches
this code where the resulting alignment would be observably different,
but the intent was clearly to use the relative offset within the new
alloca.

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

[SROA] Use the members for New{Begin,End}Offset in the rewrite helpers
rather than passing them as arguments.

While I generally prefer actual arguments, in this case the readability
loss is substantial. By using members we avoid repeatedly calculating
the offsets, and once we're using members it is useful to ensure that
those names *always* refer to the original-alloca-relative new offset
for a rewritten slice.

No functionality changed. Follow-up refactoring, all toward getting the
address space patch merged.

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

[SROA] Compute the New{Begin,End}Offset values once for each alloca
slice being rewritten.

We had the same code scattered across most of the visits. Instead,
compute the new offsets and the slice size once when we start to visit
a particular slice, and use the member variables from then on. This
reduces quite a bit of code duplication.

No functionality changed. Refactoring inspired to make it easier to
apply the address space patch to SROA.

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

Use StringRef in raw_fd_ostream constructor

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

[SROA] Fix PR18615 with some long overdue simplifications to the bounds
checking in SROA.

The primary change is to just rely on uge for checking that the offset
is within the allocation size. This removes the explicit checks against
isNegative which were terribly error prone (including the reversed logic
that led to PR18615) and prevented us from supporting stack allocations
larger than half the address space.... Ok, so maybe the latter isn't
*common* but it's a silly restriction to have.

Also, we used to try to support a PHI node which loaded from before the
start of the allocation if any of the loaded bytes were within the
allocation. This doesn't make any sense, we have never really supported
loading or storing *before* the allocation starts. The simplified logic
just doesn't care.

We continue to allow loading past the end of the allocation in part to
support cases where there is a PHI and some loads are larger than others
and the larger ones reach past the end of the allocation. We could solve
this a different and more conservative way, but I'm still somewhat
paranoid about this.

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

Remove spurious emacs major mode marker, these should only go on .h files.

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

80-col.

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

Formatting fixups.

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

Delete two declared overloads of CallInst::CallInst that are never defined or used. No functionality change.

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

Constify the Optnone checks in IR passes.

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

Simplify base64 routine a bit.

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

Exception handling docs: Describe landingpad clauses' meanings in more detail

The original text is very terse, so I've expanded on it.

Specifically, in the original text:

 * "The selector value is a positive number if the exception matched a
   type info" -- It wasn't clear that this meant "if the exception
   matched a 'catch' clause".

 * "If nothing is matched, the behavior of the program is
   `undefined`_."  -- It's actually implementation-defined in C++
   rather than undefined, as the new text explains.

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

Add DIUnspecifiedParameter, so we can pretty-print it.
This will be used for testcases in CFE.

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

fix crash in SmallDenseMap copy constructor

Prevent a crash in the SmallDenseMap copy constructor whenever the other
map is not in small mode.

<rdar://problem/14292693>

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

Use DataLayout from the module when easily available.

Eventually DataLayoutPass should go away, but for now that is the only easy
way to get a DataLayout in some APIs. This patch only changes the ones that
have easy access to a Module.

One interesting issue with sometimes using DataLayoutPass and sometimes
fetching it from the Module is that we have to make sure they are equivalent.
We can get most of the way there by always constructing the pass with a Module.
In fact, the pass could be changed to point to an external DataLayout instead
of owning one to make this stricter.

Unfortunately, the C api passes a DataLayout, so it has to be up to the caller
to make sure the pass and the module are in sync.

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

Attempt to unbreak an MSVC buildbot by switching to %llc_dwarf.

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

DwarfDebug: Avoid emitting an empty debug_aranges section when aranges are disabled

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

Address review comments for r202188.
This is refactoring / simplifying code, updating comments and enabling the
testcase on non-x86 platforms.

No functionality change.

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

Fix resetting the DataLayout in a Module.

No tool does this currently, but as everything else in a module we should be
able to change its DataLayout.

Most of the fix is in DataLayout to make sure it can be reset properly.

The test uses Module::setDataLayout since the fact that we mutate a DataLayout
is an implementation detail. The module could hold a OwningPtr<DataLayout> and
the DataLayout itself could be immutable.

Thanks to Philip Reames for pushing me in the right direction.

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

[reassociate] Switch two std::sort calls into std::stable_sort calls as
their inputs come from std::stable_sort and they are not total orders.

I'm not a huge fan of this, but the really bad std::stable_sort is right
at the beginning of Reassociate. After we commit to stable-sort based
consistent respect of source order, the downstream sorts shouldn't undo
that unless they have a total order or they are used in an
order-insensitive way. Neither appears to be true for these cases.
I don't have particularly good test cases, but this jumped out by
inspection when looking for output instability in this pass due to
changes in the ordering of std::sort.

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

R600: Don't unconditionally unroll loops with private memory accesses

This causes the size of the scrypt kernel to explode and eats all the
memory on some systems.

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

R600/SI: Custom select 64-bit ADD

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

[SROA] Add an off-by-default *strict* inbounds check to SROA. I had SROA
implemented this way a long time ago and due to the overwhelming bugs
that surfaced, moved to a much more relaxed variant. Richard Smith would
like to understand the magnitude of this problem and it seems fairly
harmless to keep some flag-controlled logic to get the extremely strict
behavior here. I'll remove it if it doesn't prove useful.

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

Account for 128-bit integer operations in PPCCTRLoops

We need to abort the formation of counter-register-based loops where there are
128-bit integer operations that might become function calls.

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

Don't try to set a dummy DataLayout. It is parsed now.

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

Store a DataLayout in Module.

Now that DataLayout is not a pass, store one in Module.

Since the C API expects to be able to get a char* to the datalayout description,
we have to keep a std::string somewhere. This patch keeps it in Module and also
uses it to represent modules without a DataLayout.

Once DataLayout is mandatory, we should probably move the string to DataLayout
itself since it won't be necessary anymore to represent the special case of a
module without a DataLayout.

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

Debug info: Support variadic functions.
Variadic functions have an unspecified parameter tag after the last
argument. In IR this is represented as an unspecified parameter in the
subroutine type.

Paired commit with CFE r202185.

rdar://problem/13690847

This re-applies r202184 + a bugfix in DwarfDebug's argument handling.

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

Revert "Debug info: Support variadic functions."

This reverts commit r202184 because of buildbot breakage.

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

Remove outdated comments.

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

Debug info: Support variadic functions.
Variadic functions have an unspecified parameter tag after the last
argument. In IR this is represented as an unspecified parameter in the
subroutine type.

Paired commit with CFE.

rdar://problem/13690847

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

[XCore] Add intrinsic for CLRPT (clear port time) instruction.

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

[XCore] Add intrinsic for EDU (event disable unconditional) instruction.

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

Make DataLayout a plain object, not a pass.

Instead, have a DataLayoutPass that holds one. This will allow parts of LLVM
don't don't handle passes to also use DataLayout.

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

Keep the link register for uwtable.

The function with uwtable attribute might be visited by the
stack unwinder, thus the link register should be considered
as clobbered after the execution of the branch and link
instruction (i.e. the definition of the machine instruction
can't be ignored) even when the callee function are marked
with noreturn.

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

[XCore] Prefer to word align functions.

The behaviour of the XCore's instruction buffer means that the performance
of the same code sequence can differ depending on whether it starts at a 4
byte aligned address or not. Since we don't model the instruction buffer
in the backend we have no way of knowing for sure if it is beneficial to
word align a specific function. However, in the absence of precise
modelling, it is better on balance to word align functions because:

* It makes a fetch-nop while executing the prologue slightly less likely.
* If we don't word align functions then a small perturbation in one
  function can have a dramatic knock on effect. If the size of the function
  changes it might change the alignment and therefore the performance of
  all the functions that happen to follow it in the binary. This butterfly
  effect makes it harder to reason about and measure the performance of
  code.

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

Factor out calls to AA.getDataLayout().

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

Make a few more DataLayout variables const.

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

[SROA] Use the original load name with the SROA-prefixed IRB rather than
just "load". This helps avoid pointless de-duping with order-sensitive
numbers as we already have unique names from the original load. It also
makes the resulting IR quite a bit easier to read.

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

[SROA] Thread the ability to add a pointer-specific name prefix through
the pointer adjustment code. This is the primary code path that creates
totally new instructions in SROA and being able to lump them based on
the pointer value's name for which they were created causes
*significantly* fewer name collisions and general noise in the debug
output. This is particularly significant because it is making it much
harder to track down instability in the output of SROA, as name
de-duplication is a totally harmless form of instability that gets in
the way of seeing real problems.

The new fancy naming scheme tries to dig out the root "pre-SROA" name
for pointer values and associate that all the way through the pointer
formation instructions. Digging out the root is important to prevent the
multiple iterative rounds of SROA from just layering too much cruft on
top of cruft here. We already track the layers of SROAs iteration in the
alloca name prefix. We don't need to duplicate it here.

Should have no functionality change, and shouldn't have any really
measurable impact on NDEBUG builds, as most of the complex logic is
debug-only.

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

[SROA] Rather than copying the logic for building a name prefix into the
PHI-pointer builder, just copy the builder and clobber the obvious
fields.

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

[SROA] Simplify some of the logic to dig out the old pointer value by
using OldPtr more heavily. Lots of this code was written before the
rewriter had an OldPtr member setup ahead of time. There are already
asserts in place that should ensure this doesn't change any
functionality.

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

[SROA] Adjust to new clang-format style.

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

Reuse constants for COFF string table entry offsets

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

[SROA] Fix a *glaring* bug in r202091: you have to actually *write*
the break statement, not just think it to yourself....

No idea how this worked at all, much less survived most bots, my
bootstrap, and some bot bootstraps!

The Polly one didn't survive, and this was filed as PR18959. I don't
have a reduced test case and honestly I'm not seeing the need. What we
probably need here are better asserts / debug-build behavior in
SmallPtrSet so that this madness doesn't make it so far.

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

Disable old JIT unittests for AARch64

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

Ignore old JIT tests in AARch64 - CMake style

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

Add aarch64 to config.guess

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

Silence GCC warning

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

Fix typos

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

[SROA] Add a debugging tool which shuffles the slices sequence prior to
sorting it. This helps uncover latent reliance on the original ordering
which aren't guaranteed to be preserved by std::sort (but often are),
and which are based on the use-def chain orderings which also aren't
(technically) guaranteed.

Only available in C++11 debug builds, and behind a flag to prevent noise
at the moment, but this is generally useful so figured I'd put it in the
tree rather than keeping it out-of-tree.

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

[SROA] Use a more direct way of determining whether we are processing
the destination operand or source operand of a memmove.

It so happens that it was impossible for SROA to try to rewrite
self-memmove where the operands are *identical*, because either such
a think is volatile (and we don't rewrite) or it is non-volatile, and we
don't even register it as a use of the alloca.

However, making the 'IsDest' test *rely* on this subtle fact is... Very
confusing for the reader. We should use the direct and readily available
test of the Use* which gives us concrete information about which operand
is being rewritten.

No functionality changed, I hope! ;]

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

Add some convenience accessors for the underlying Use of an operand.
These complement many of the existing accessors and make it
significantly easier to write code which needs to poke at the underlying
Use without hard coding the operand number at which it resides for
a particular instruction. No functionality changed of course.

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

Indent this continued line.

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

[SROA] Fix another instability in SROA with respect to the slice
ordering.

The fundamental problem that we're hitting here is that the use-def
chain ordering is *itself* not a stable thing to be relying on in the
rewriting for SROA. Further, we use a non-stable sort over the slices to
arrange them based on the section of the alloca they're operating on.
With a debugging STL implementation (or different implementations in
stage2 and stage3) this can cause stage2 != stage3.

The specific aspect of this problem fixed in this commit deals with the
rewriting and load-speculation around PHIs and Selects. This, like many
other aspects of the use-rewriting in SROA, is really part of the
"strong SSA-formation" that is doen by SROA where it works very hard to
canonicalize loads and stores in *just* the right way to satisfy the
needs of mem2reg[1]. When we have a select (or a PHI) with 2 uses of the
same alloca, we test that loads downstream of the select are
speculatable around it twice. If only one of the operands to the select
needs to be rewritten, then if we get lucky we rewrite that one first
and the select is immediately speculatable. This can cause the order of
operand visitation, and thus the order of slices to be rewritten, to
change an alloca from promotable to non-promotable and vice versa.

The fix is to defer all of the speculation until *after* the rewrite
phase is done. Once we've rewritten everything, we can accurately test
for whether speculation will work (once, instead of twice!) and the
order ceases to matter.

This also happens to simplify the other subtlety of speculation -- we
need to *not* speculate anything unless the result of speculating will
make the alloca fully promotable by mem2reg. I had a previous attempt at
simplifying this, but it was still pretty horrible.

There is actually already a *really* nice test case for this in
basictest.ll, but on multiple STL implementations and inputs, we just
got "lucky". Fortunately, the test case is very small and we can
essentially build it in exactly the opposite way to get reasonable
coverage in both directions even from normal STL implementations.

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

llvm-dwarfdump: Support for debug_line.dwo section for file names for type units under fission.

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

Make some DataLayout pointers const.

No functionality change. Just reduces the noise of an upcoming patch.

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

Permit CMAKE_INSTALL_RPATH to be set on command line

Commit 201921 overrides setting of CMAKE_INSTALL_RPATH via the
command line. Last time this happened we applied another patch
to only set CMAKE_INSTALL_RPATH if already defined (r197825).
This patch does the same thing again, but only for the UNIX
case - we leave APPLE alone as presumably the original committer
is happy with the non-overriding behaviour.

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

trivial test commit

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

llvm-objdump: Do not attempt to disassemble symbols outside of section
boundaries.

It is possible to create an ELF executable where symbol from say .text
section 'points' to the address outside the section boundaries. It does
not have a sense to disassemble something outside the section.

Without this fix llvm-objdump prints finite or infinite (depends on
the executable file architecture) number of 'invalid instruction
encoding' warnings.

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

Disable an MCJIT test on older Darwins until we have a better interface.

See
<rdar://16149106> [MCJIT] provide a platform-independent way to communicate callee-save frame info.
<rdar://16149279> [MCJIT] get the host OS version from a runtime check, not a configure-time check.

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

Fix unused variable

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

R600/SI - Add new CI arithmetic instructions.

Does not yet include larger part required
to match v_mad_i64_i32 / v_mad_u64_u32.

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

R600: Make check clearer.

The check is clearer as southern islands or later,
rather than checking for later than northern islands.

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

Fix DOT4 missing from getTargetOpcodeName

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

Add missing const

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

Trivial code simplification

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

SLPVectorizer: Try vectorizing 'splat' stores

Vectorize sequential stores of a broadcasted value.
5% on eon.

radar://16124699

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

[X86][SchedModel] Add missing scheduling model for SSE related instructions.

The patch defines new or refines existing generic scheduling classes to match
the behavior of the SSE instructions.
It also maps those scheduling classes on the related SSE instructions.

<rdar://problem/15607571>

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

Add a dwarf number to the Y register.

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

Replace the F_Binary flag with a F_Text one.

After this I will set the default back to F_None. The advantage is that
before this patch forgetting to set F_Binary would corrupt a file on windows.
Forgetting to set F_Text produces one that cannot be read in notepad, which
is a better failure mode :-)

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

LTO: Add the loop vectorizer to the LTO pipeline.

During the LTO phase LICM will move loop invariant global variables out of loops
(informed by GlobalModRef). This makes more loops countable presenting
opportunity for the loop vectorizer.

Adding the loop vectorizer improves some TSVC benchmarks and twolf/ref dataset
(5%) on x86-64.

radar://15970632

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

Fix windows unittest I missed in the raw_fd_ostream constructor change.

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

For lcov tests, don't Xfail mips littl endian (mipsel-... and mip64el-...)
targets. Just big endian (mips-... and mips64-...)

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

Don't make F_None the default.

This will make it easier to switch the default to being binary files.

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

[CMake] Remove dependency on non-existing profile_rt-shared. Patch by Brad King.

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

[asan] remove test that should have been removed in r202033

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

[asan] simplify the code that compute the shadow offset; get rid of two internal flags that allowed to override it. The tests pass, but still this change might break asan on some platform not covered by tests. If you see this, please submit a fix with a test.

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

Add AArch64 big endian Target (aarch64_be)

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

AVX-512: Fixed encoding of VPCMPEQ and VPCMPGT

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

Share a createUniqueEntity implementation between unix and windows.

The only extra bit of functionality that had to be exposed for this be be
implemented in Path.cpp is opening a file in rw mode.

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

Delete dead code.

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

Asm Parser: support .error directive

The .error directive is similar to .err in that it will halt assembly if it is
evaluated for assembly.  However, it permits a user supplied message to be
rendered.

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

AsmParser: support .ifeqs directive

The .ifeqs directive assembles the following code if the quoted string
parameters are equal.  The strings must be quoted using double quotes.

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

SPARC: Implement TRAP lowering. Matches what GCC emits.

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

ARMAsmParser: whitespace

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

ARM IAS: support .align without parameters

.align is handled specially on certain targets.  .align without any parameters
on ARM indicates a default alignment (4).  Handle the special case in the target
parser, but fall back to the generic parser for the normal version.

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

MCAsmParser: support .ifne

The .ifne directive assembles the following section of code if the argument
expression is non-zero.  Effectively, it is equivalent to if.

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

MCAsmParser: handle space properly for .ifc/.ifnc

If the strings are not quoted, the first string stops at the first comma, and
the second string stops at the end of the line.  Strings which contain
whitespace should be quoted.  Unquoted space is to be discarded.

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

MCAsmParser: add support for .err directive

The .err directive produces an error whenever it is assembled.  This can be
useful for preventing assembly when an unexpected condition occurs.

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

Use static instead of an anonymous namespace.

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

AVX-512: Fixed encoding of VPTESTMQ

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

Simplify remove, create_directory and create_directories.

Before this patch they would take an boolean argument to say if the path
already existed. This was redundant with the returned error_code which is able
to represent that. This allowed for callers to incorrectly check only the
existed flag instead of first checking the error code.

Instead, pass in a boolean flag to say if the previous (non-)existence should be
an error or not.

Callers of the of the old simple versions are not affected. They still ignore
the previous (non-)existence as they did before.

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