[LoopVectorize] Extract InductionInfo into a helper class...

... and move it into LoopUtils where it can be used by other passes, just like ReductionDescriptor. The API is very similar to ReductionDescriptor - that is, not very nice at all. Sorting these both out will come in a followup.

NFC

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

Whoops, remove trailing whitespace.

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

isKnownNonNull needs to consider globals in non-zero address spaces.

Globals in address spaces other than one may have 0 as a valid address,
so we should not assume that they can be null.

Reviewed by Philip Reames.

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

Allow value forwarding past release fences in EarlyCSE

A release fence acts as a publication barrier for stores within the current thread to become visible to other threads which might observe the release fence. It does not require the current thread to observe stores performed on other threads. As a result, we can allow store-load and load-store forwarding across a release fence.

We do need to make sure that stores before the fence can't be eliminated even if there's another store to the same location after the fence. In theory, we could reorder the second store above the fence and *then* eliminate the former, but we can't do this if the stores are on opposite sides of the fence.

Note: While more aggressive then what's there, this patch is still implementing a really conservative ordering.  In particular, I'm not trying to exploit undefined behavior via races, or the fact that the LangRef says only 'atomic' accesses are ordered w.r.t. fences.

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

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

[RewriteStatepointsForGC] Reduce the number of new instructions for base pointers

When computing base pointers, we introduce new instructions to propagate the base of existing instructions which might not be bases. However, the algorithm doesn't make any effort to recognize when the new instruction to be inserted is the same as an existing one already in the IR. Since this is happening immediately before rewriting, we don't really have a chance to fix it after the pass runs without teaching loop passes about statepoints.

I'm really not thrilled with this patch. I've rewritten it 4 different ways now, but this is the best I've come up with. The case where the new instruction is just the original base defining value could be merged into the existing algorithm with some complexity. The problem is that we might have something like an extractelement from a phi of two vectors. It may be trivially obvious that the base of the 0th element is an existing instruction, but I can't see how to make the algorithm itself figure that out. Thus, I resort to the call to SimplifyInstruction instead.

Note that we can only adjust the instructions we've inserted ourselves. The live sets are still being tracked in side structures at this point in the code. We can't easily muck with instructions which might be in them. Long term, I'm really thinking we need to materialize the live pointer sets explicitly in the IR somehow rather than using side structures to track them.

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

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

Improved printing of analysis diagnostics in the loop vectorizer.

This patch ensures that every analysis diagnostic produced by the vectorizer
will be printed if the loop has a vectorization hint on it. The condition has
also been improved to prevent printing when a disabling hint is specified.

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

Fixed a bug that edge weights are not assigned correctly when lowering switch statement.

This is a one-line-change patch that moves the update to UnhandledWeights to the correct position: it should be updated for all clusters instead of just range clusters.

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

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

Kaleidoscope: Prune unused libdeps.

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

[SimplifyCFG] Prune code from a provably unreachable switch default

As Sanjoy pointed out over in http://reviews.llvm.org/D11819, a switch on an icmp should always be able to become a branch instruction. This patch generalizes that notion slightly to prove that the default case of a switch is unreachable if the cases completely cover all possible bit patterns in the condition. Once that's done, the switch to branch conversion kicks in just fine.

Note: Duplicate case values are disallowed by the LangRef and verifier.

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

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

[PowerPC] Remove unnecessary braces in PPCVSXFMAMutate

Address Eric's post-commit review of r245741. NFC.

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

[NVPTX] Let NVPTX backend detect integer min and max patterns.

Summary:
Let NVPTX backend detect integer min and max patterns during isel and emit intrinsics that enable hardware support.

Reviewers: jholewinski, meheff, jingyue

Subscribers: arsenm, llvm-commits, meheff, jingyue, eliben, jholewinski

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

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

[ARM] Use BranchProbability::scale() to scale an integer with a probability in ARMBaseInstrInfo.cpp,

Previously in isProfitableToIfCvt() in ARMBaseInstrInfo.cpp, the multiplication between an integer and a branch probability is done manually in an unsafe way that may lead to overflow. This patch corrects those cases by using BranchProbability's member function scale() to avoid overflow (which stores the intermediate result in int64).

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

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

Assign weights to edges to jump table / bit test header when lowering switch statement.

Currently, when lowering switch statement and a new basic block is built for jump table / bit test header, the edge to this new block is not assigned with a correct weight. This patch collects the edge weight from all its successors and assign this sum of weights to the edge (and also the other fall-through edge). Test cases are adjusted accordingly.

Differential Revision: http://reviews.llvm.org/D12166#fae6eca7

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

[docs][Statepoints] More on base pointers

Expand the information on base pointers to include an example, the assumptions a collector is allowed to make, legal optimizations over gc.relocates, and the assumptions made by RewriteStatepointsForGC.  This is the result of a recent conversation with folks from LLIC and the confusions that came to light therein.

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

WebAssembly: NFC comment update

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

DI: Make Subprogram definitions 'distinct'

Change `DIBuilder` always to produce 'distinct' nodes when creating
`DISubprogram` definitions.  I measured a ~5% memory improvement in the
link step (of ld64) when using `-flto -g`.

`DISubprogram`s are used in two ways in the debug info graph.

Some are definitions, point at actual functions, and can't really be
shared between compile units.  With full debug info, these point down at
their variables, forming uniquing cycles.  These uniquing cycles are
expensive to link between modules, since all unique nodes that reference
them transitively need to be duplicated (see commit message for r244181
for more details).

Others are declarations, primarily used for member functions in the type
hierarchy.  Definitions never show up there; instead, a definition
points at its corresponding declaration node.

I started by making all subprograms 'distinct'.  However, that was too
big a hammer: memory usage *increased* ~5% (net increase vs. this patch
of ~10%) because the 'distinct' declarations undermine LTO type
uniquing.  This is a targeted fix for the definitions (where uniquing is
an observable problem).

A couple of notes:

  - There's an accompanying commit to update IRGen testcases in clang.
  - ^ That's what I'm using to test this commit.
  - In a follow-up, I'll change the verifier to require 'distinct' on
    definitions and add an upgrade to `BitcodeReader`.

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

WebAssembly: handle private/internal globals.

Things of note:
 - Other linkage types aren't handled yet. We'll figure it out with dynamic linking.
 - Special LLVM globals are either ignored, or error out for now.
 - TLS isn't supported yet (WebAssembly will have threads later).
 - There currently isn't a syntax for alignment, I left it in a comment so it's easy to hook up.
 - Undef is convereted to whatever the type's appropriate null value is.
 - assert versus report_fatal_error: follow what other AsmPrinters do, and assert only on what should have been caught elsewhere.

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

[ms-inline-asm] Relax assertion around funky identifiers slightly

A corresponding clang change will make it so that clang can consume part
of an assembler token. The assembler treats '.' as an identifier
character while clang does not, so it's view of the token stream is a
little different.

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

[libFuzzer] fix minor inefficiency, PR24584

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

Fix LLVM C API for DataLayout

We removed access to the DataLayout on the TargetMachine and
deprecated the C API function LLVMGetTargetMachineData() in r243114.
However the way I tried to be backward compatible was broken: I
changed the wrapper of the TargetMachine to be a structure that
includes the DataLayout as well. However the TargetMachine is also
wrapped by the ExecutionEngine, in the more classic way. A client
using the TargetMachine wrapped by the ExecutionEngine and trying
to get the DataLayout would break.

It seems tricky to solve the problem completely in the C API
implementation. This patch tries to address this backward
compatibility in a more lighter way in the C++ API. The C API is
restored in its original state and the removed C++ API is
reintroduced, but privately. The C API is friended to the
TargetMachine and should be the only consumer for this API.

Reviewers: ributzka

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

From: Mehdi Amini <mehdi.amini@apple.com>

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

[Kaleidoscope] Fix a typo in Chapter 5.

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

AMDGPU: Delete dead code

There is no context where s_mov_b64 is emitted
and could potentially be moved to the VALU.
It is currently only emitted for materializing
immediates, which can't be dependent on vector sources.

The immediate splitting is already done when selecting
constants. I'm not sure what contexts if any the register
splitting would have been used before.

Also clean up using s_mov_b64 in place of v_mov_b64_pseudo,
although this isn't required and just skips the extra step
of eliminating the copy from the SReg_64.

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

AMDGPU: Don't reprocess instructions when splitting i64 bcnt

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

AMDGPU: Fix not moving users of s_bfe_i64 to VALU

This wouldn't propagate to users of the original BFE
and would hit a verifier error.

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

AMDGPU: Don't create intermediate SALU instructions

When splitting 64-bit operations, create the correct
VALU instructions immediately.

This was splitting things like s_or_b64 into the two
s_or_b32s and then pushing the new instructions
onto the worklist. There's no reason we need
to do this intermediate step.

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

SelectionDAGBuilder: Fix SPDescriptor not resetting GuardReg

This was causing problems when some functions use a GuardReg and some
don't as can happen when mixing SelectionDAG and FastISel generated
functions.

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

FastISel: Avoid adding a successor block twice for degenerate IR.

This fixes http://llvm.org/PR24581

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

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

Expose hasLiveCondCodeDef as a member function of the X86InstrInfo class. NFC

This takes the existing static function hasLiveCondCodeDef and makes it a member function of the X86InstrInfo class. This is a useful utility function that an upcoming change would like to use. NFC.

Patch by: Kevin B. Smith
Differential Revision: http://reviews.llvm.org/D12371

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

Fix memory leak in sample profile pass.

The problem here were the function analyses invoked by the function pass
manager from the new IPO pass. I looked at other IPO passes needing
dominance information and the only one that requires it (partial
inliner) does not use the standard dependency mechanism.

This patch mimics what the partial inliner does to compute dominance,
post-dominance and loop info. One thing I like about this approach is
that I can delay the computation of all this until I actually need it.

This should bring the ASAN buildbot back to green. If there's a better
way to fix this, I'll do it in a follow-up patch.

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

Revert "Fix LLVM C API for DataLayout"

This reverts commit r246052.
Third attempt, still unpleasant for some bots.

From: Mehdi Amini <mehdi.amini@apple.com>

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

AMDGPU/SI: Report SIFixSGPRLiveRanges changed function

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

Fix LLVM C API for DataLayout

We removed access to the DataLayout on the TargetMachine and
deprecated the C API function LLVMGetTargetMachineData() in r243114.
However the way I tried to be backward compatible was broken: I
changed the wrapper of the TargetMachine to be a structure that
includes the DataLayout as well. However the TargetMachine is also
wrapped by the ExecutionEngine, in the more classic way. A client
using the TargetMachine wrapped by the ExecutionEngine and trying
to get the DataLayout would break.

It seems tricky to solve the problem completely in the C API
implementation. This patch tries to address this backward
compatibility in a more lighter way in the C++ API. The C API is
restored in its original state and the removed C++ API is
reintroduced, but privately. The C API is friended to the
TargetMachine and should be the only consumer for this API.

Reviewers: ributzka

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

From: Mehdi Amini <mehdi.amini@apple.com>

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

AMDGPU: Make sure to reserve super registers

I think this could potentially have broken if
one of the super registers were allocated
that contain v254/v255.

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

Revert "Fix LLVM C API for DataLayout"

This reverts commit r246044.
Build broken, still. It builds for me...

From: Mehdi Amini <mehdi.amini@apple.com>

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

AMDGPU: Produce error on dynamic_stackalloc

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

[SimplifyLibCalls] Fix a typo

cbrt(sqrt(x)) calculates the sixth root, not the ninth root.
cbrt(cbrt(x)) calculates the ninth root.

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

Fix LLVM C API for DataLayout

We removed access to the DataLayout on the TargetMachine and
deprecated the C API function LLVMGetTargetMachineData() in r243114.
However the way I tried to be backward compatible was broken: I
changed the wrapper of the TargetMachine to be a structure that
includes the DataLayout as well. However the TargetMachine is also
wrapped by the ExecutionEngine, in the more classic way. A client
using the TargetMachine wrapped by the ExecutionEngine and trying
to get the DataLayout would break.

It seems tricky to solve the problem completely in the C API
implementation. This patch tries to address this backward
compatibility in a more lighter way in the C++ API. The C API is
restored in its original state and the removed C++ API is
reintroduced, but privately. The C API is friended to the
TargetMachine and should be the only consumer for this API.

Reviewers: ributzka

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

From: Mehdi Amini <mehdi.amini@apple.com>

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

[SPARC] Fix stupid oversight in stack realignment support.

If you're going to realign %sp to get object alignment properly (which
the code does), and stack offsets and alignments are calculated going
down from %fp (which they are), then the total stack size had better
be a multiple of the alignment. LLVM did indeed ensure that.

And then, after aligning, the sparc frame code added 96 (for sparcv8)
to the frame size, making any requested alignment of 64-bytes or
higher *guaranteed* to be misaligned. The test case added with r245668
even tests this exact scenario, and asserted the incorrect behavior,
which I somehow failed to notice. D'oh.

This change fixes the frame lowering code to align the stack size
*after* adding the spill area, instead.

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

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

[docs][Statepoint] Add definitions for base and derived pointers

This section will be expanded over the next few days.  This is just some initial content.

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

[llvm-mc] Ignore opcode size prefix in 64-bit CALL disassembly

This is a fix for disassembling unusual instruction sequences in 64-bit
mode w.r.t the CALL rel16 instruction. It might be desirable to move the
check somewhere else, but it essentially mimics the special case
handling with JCXZ in 16-bit mode.

The current behavior accepts the opcode size prefix and causes the
call's immediate to stop disassembling after 2 bytes. When debugging
sequences of instructions with this pattern, the disassembler output
becomes extremely unreliable and essentially useless (if you jump midway
into what lldb thinks is a unified instruction, you'll lose %rip). So we
ignore the prefix and consume all 4 bytes when disassembling a 64-bit
mode binary.

Note: in Vol. 2A 3-99 the Intel spec states that CALL rel16 is N.S. N.S.
is defined as:

    Indicates an instruction syntax that requires an address override
    prefix in 64-bit mode and is not supported. Using an address
    override prefix in 64-bit mode may result in model-specific
    execution behavior. (Vol. 2A 3-7)

Since 0x66 is an operand override prefix we should be OK (although we
may want to warn about 0x67 prefixes to 0xe8). On the CPUs I tested
with, they all ignore the 0x66 prefix in 64-bit mode.

Patch by Matthew Barney!

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

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

[AArch64] Remove a use-after-free when collecting stats.

The call to mergePairedInsns() deletes MI, so the later use by isUnscaledLdSt()
is referencing freed memory.

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

[llvm-objdump] Use the new MinVersion API introduced in r245938. NFC.

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

[AArch64] Unify the integer min/max vector selection patterns with the intrinsic ones

Summary:
This change lowers the aarch64 integer vector min/max intrinsic nodes to
generic min/max nodes and replaces the intrinsic selection patterns with
the generic ones.

There should already be testing in place for this, so no further tests
were added.

Reviewers: jmolloy

Subscribers: aemerson, llvm-commits, rengolin

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

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

[SROA] Rip out all support for SSAUpdater in SROA.

This was only added to preserve the old ScalarRepl's use of SSAUpdater
which was originally to avoid use of dominance frontiers. Now, we only
need a domtree, and we'll need a domtree right after this pass as well
and so it makes perfect sense to always and only use the dom-tree
powered mem2reg. This was flag-flipper earlier and has stuck reasonably
so I wanted to gut the now-dead code out of SROA before we waste more
time with it. Among other things, this will make passmanager porting
easier.

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

Kaleidoscope: Update libdeps corresponding to r246002.

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

Revert "[dsymutil] Emit real dSYM companion binaries."

This reverts commit r246012.
Some bots do not like it (mips/s390).

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

Modernize with range-based for loops.

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

Reduce code duplication.

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

Trailing whitespace

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

[dsymutil] Emit real dSYM companion binaries.

The binaries containing the linked DWARF generated by dsymutil are not
standard relocatable object files like emitted did previsously. They should be
dSYM companion files, which means they have a different file type in the
header, but also a couple other peculiarities:
 - they contain the segments and sections from the original binary in their
load commands, but not the actual contents. This means they get an address
and a size, but their offset is always 0 (but these are not virtual sections)
 - they also conatin all the defined symbols from the original binary

This makes MC a really bad fit to emit these kind of binaries. The approach
that was used in this patch is to leverage MC's section layout for the
debug sections, but to use a replacement for MachObjectWriter that lives
in MachOUtils.cpp. Some of the low-level helpers from MachObjectWriter
were reused too.

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

[dsymutil] Store an optional BinaryPath in the debug map.

llvm-dsymutil needs to emit dSYM companion bundles. These are binary files
that replicate some of the orignal binary file properties (sections and
symbols). To get acces to these properties, pass the binary path in the
debug map.

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

[dsymutil] Make the warn and error helpers globally available. NFC.

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

[dsymutil] Split NonRelocatableStringPool into its own file. NFC.

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

[MC] Split the layout part of MCAssembler::finish() into its own method. NFC.

Split a MCAssembler::layout() method out of MCAssembler::finish(). This allows
running the MCSections layout separately from the streaming of the output
file. This way if a client wants to use MC to generate section contents, but
emit something different than the standard relocatable object files it is
possible (llvm-dsymutil is such a client).

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

[MC/MachO] Make some MachObjectWriter methods more generic. NFC.

Hardcode less values in some mach-o header writing routines and pass them
as argument. Doing so will allow reusing this code in llvm-dsymutil.

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

Big Kaleidoscope tutorial update.

This commit switches the underlying JIT for the Kaleidoscope tutorials from
MCJIT to a custom ORC-based JIT, KaleidoscopeJIT. This fixes a lot of the bugs
in Kaleidoscope that were introduced when we deleted the legacy JIT. The
documentation for Chapter 4, which introduces the JIT APIs, is updated to
reflect the change.

Also included are a number of C++11 modernizations and general cleanup. Where
appropriate, the docs have been updated to reflect these changes too.

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

Comparing operands should not require the same ValueID

Summary: When comparing basic blocks, there is an additional check that two Value*'s should have the same ID, which interferes with merging equivalent constants of different kinds (such as a ConstantInt and a ConstantPointerNull in the included testcase). The cmpValues function already ensures that the two values in each function are the same, so removing this check should not cause incorrect merging.

Also, the type comparison is redundant, based on reviewing the code and testing on the test suite and several large LTO bitcodes.

Author: jrkoenig
Reviewers: nlewycky, jfb, dschuff
Subscribers: llvm-commits
Differential revision: http://reviews.llvm.org/D12302

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

Expose more properties of llvm::fltSemantics

Summary: Adds accessor functions for all the fields in llvm::fltSemantics. This will be used in MergeFunctions to order two APFloats with different semanatics.

Author: jrkoenig
Reviewers: jfb
Subscribers: dschuff, llvm-commits
Differential revision: http://reviews.llvm.org/D12253

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

FastISel: Use finishCondBranch() for ARM,Mips,PowerPC FastISel

Note that after this change branch probabilities are preserved now.

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

FastISel: Factor out common code; NFC intended

This should be no functional change but for the record: For three cases
in X86FastISel this will change the order in which the FalseMBB and
TrueMBB of a conditional branch is addedd to the successor/predecessor
lists.

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

WebAssembly: add small FIXME for AsmPrinter.

Suggested by @sunfish as a follow-up to r245982.

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

Refactor to reduce duplication in OnDiskIterableChainedHashTable's iterators.

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

[dsymutil] actually fix test.

Not all machines have lipo installed. Do not try to invoke it.

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

Make variable argument intrinsics behave correctly in a Win64 CC function.

Summary:
This change makes the variable argument intrinsics, `llvm.va_start` and
`llvm.va_copy`, and the `va_arg` instruction behave as they do on Windows
inside a `CallingConv::X86_64_Win64` function. It's needed for a Clang patch
I have to add support for GCC's `__builtin_ms_va_list` constructs.

Reviewers: nadav, asl, eugenis

CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1622

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

WebAssembly: assert that there aren't any constant pools

WebAssembly will either use globals or immediates, since it's a virtual ISA.

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

[dsymutil] Reapply r245960.

There was an issue in the test setup because the test requires an arch that
wasn't filtered by the lit.local.cfg, but given the set of bots that failed,
I'm not confident this is the (only) issue. So this commit also adds more
output to the test to help me track down the failure if it happens again.

Original commit message:
[dsymutil] Rewrite thumb triple names in user visible messages.

We autodetect triples from the input file(s) while reading the mach-o debug map.
As we need to create a Target from those triples, we always chose the thumb
variant (because the arm variant might not be 'instantiable' eg armv7m). The
user visible architecture names should still be 'arm' and not 'thumb' variants
though.

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

WebAssembly: emit `(func (param t) (result t))` s-expressions

Summary: Match spec format: https://github.com/WebAssembly/spec/blob/master/ml-proto/test/fac.wasm

Reviewers: sunfish

Subscribers: llvm-commits, jfb

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

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

WebAssembly: comment out .globl when printing textual assembly

Do the same for .weak (not implemented for now, but may as well to it). Update comment string to two semicolons.

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

[msan] Precise instrumentation for icmp sgt %x, -1.

Extend signed relational comparison instrumentation with a special
case for comparisons with -1. This fixes an MSan false positive when
such comparison is used as a sign bit test.

https://llvm.org/bugs/show_bug.cgi?id=24561

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

[MC] Add a SetUsed default param to MCSymbol accessors (NFC)

Reviewed by: rafael

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

MachineBasicBlock: Use MCPhysReg instead of unsigned in livein API

This is friendlier to the readers as it makes it clear that the API is
not meant for vregs but just for physregs.

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

Remove the final bit test during lowering switch statement if all cases in bit test cover a contiguous range.

When lowering switch statement, if bit tests are used then LLVM will always generates a jump to the default statement in the last bit test. However, this is not necessary when all cases in bit tests cover a contiguous range. This is because when generating the bit tests header MBB, there is a range check that guarantees cases in bit tests won't go outside of [low, high], where low and high are minimum and maximum case values in the bit tests. This patch checks if this is the case and then doesn't emit jump to default statement and hence saves a bit test and a branch.

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

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

Use CHECK-LABEL in MSan IR tests.

This actually found one case when a test was matching instructions
from the output of a different test.

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

Revert "[dsymutil] Rewrite thumb triple names in user visible messages."

This reverts commit r245960.

Multiple bots are failing on the new test. It seemd like llvm-dsymutil exits with an error. Investigating.

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

[MachO] Move trivial accessors to header.

Requested by: Jim Grosbach.

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

[dsymutil] Rewrite thumb triple names in user visible messages.

We autodetect triples from the input file(s) while reading the mach-o debug map.
As we need to create a Target from those triples, we always chose the thumb
variant (because the arm variant might not be 'instantiable' eg armv7m). The
user visible architecture names should still be 'arm' and not 'thumb' variants
though.

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

[dsymutil] Not finding any debug info is not a fatal error

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

fix CHECK-LABEL and wrong label

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

Update libdeps in LLVMipo and LLVMScalarOpts, corresponding to r245940.

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

SlotIndexes: Introduce an iterator into the idx2MBBMap.

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

Fix dependencies/shared library build

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

Fix dropped conditional in cleanup in r245752

Code review feedback by Charlie Turner.

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

The patch replace the overflow check in loop vectorization with the minimum loop iterations check.

The loop minimum iterations check below ensures the loop has enough trip count so the generated
vector loop will likely be executed, and it covers the overflow check.

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

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

make fast unaligned memory accesses implicit with SSE4.2 or SSE4a

This is a follow-on from the discussion in http://reviews.llvm.org/D12154.

This change allows memset/memcpy to use SSE or AVX memory accesses for any chip that has
generally fast unaligned memory ops.

A motivating use case for this change is a clang invocation that doesn't explicitly set
the CPU, but does target a feature that we know only exists on a CPU that supports fast
unaligned memops. For example:
$ clang -O1 foo.c -mavx

This resolves a difference in lowering noted in PR24449:
https://llvm.org/bugs/show_bug.cgi?id=24449

Before this patch, we used different store types depending on whether the example can be
lowered as a memset or not.

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

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

[lit] Speculatively fix PR24554 by manually closing the process handle

My theory is that somehow Python's refcounting and GC strategy isn't
closing the subprocess handle in a timely fashion.  This accesses the
private '_handle' field of the Popen object, but I see no other way to
do this. If this doesn't address the problem on the sanitizer-windows
buildbot, we can revert this change. If it does, then let's keep the
hack.

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

[cmake] Pass /manifest:no to the linker when asan is enabled

This is a workaround for PR24476.

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

Convert SampleProfile pass into a Module pass.

Eventually, we will need sample profiles to be incorporated into the
inliner's cost models.  To do this, we need the sample profile pass to
be a module pass.

This patch makes no functional changes beyond the mechanical adjustments
needed to run SampleProfile as a module pass.

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

[MachO] Introduce MinVersion API.

While introducing support for MinVersionLoadCommand in llvm-readobj I noticed there's
no API to extract Major/Minor/Update components conveniently. Currently consumers
do the bit twiddling on their own, but this will change from now on.

I'll convert llvm-objdump (and llvm-readobj) in a later commit.

Differential Revision:  http://reviews.llvm.org/D12282
Reviewed by: rafael

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

[X86] Remove references to _ftol2

As of r245924, _ftol2 is no longer used for fptoui on MS platforms.
Remove the dead code associated with it.

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

[X86] Fix fptoui conversions

This fixes two issues in x86 fptoui lowering.
1) Makes conversions from f80 go through the right path on AVX-512.
2) Implements an inline sequence for fptoui i64 instead of a library
call. This improves performance by 6X on SSE3+ and 3X otherwise.
Incidentally, it also removes the use of ftol2 for fptoui, which was
wrong to begin with, as ftol2 converts to a signed i64, producing
wrong results for values >= 2^63.

Patch by: mitch.l.bodart@intel.com
Differential Revision: http://reviews.llvm.org/D11316

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

Pass function attributes instead of boolean in isIntDivCheap().

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

assume.ll test fixup

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

Assume intrinsic handling in global opt

It doesn't solve the problem, when for example we load something, and
then assume that it is the same as some constant value, because
globalopt will fail on unknown load instruction. The proposed solution
would be to skip some instructions that we can't evaluate and they are
safe to skip (f.e. load, assume and many others) and see if they are
required to perform optimization (f.e. we don't care about ephemeral
instructions that may appear using @llvm.assume())

http://reviews.llvm.org/D12266

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

Revert "Fix LLVM C API for DataLayout"

This reverts commit 433bfd94e4b7e3cc3f8b08f8513ce47817941b0c.
Broke some bot, have to see why it passed locally.

From: Mehdi Amini <mehdi.amini@apple.com>

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

Fix LLVM C API for DataLayout

We removed access to the DataLayout on the TargetMachine and
deprecated the C API function LLVMGetTargetMachineData() in r243114.
However the way I tried to be backward compatible was broken: I
changed the wrapper of the TargetMachine to be a structure that
includes the DataLayout as well. However the TargetMachine is also
wrapped by the ExecutionEngine, in the more classic way. A client
using the TargetMachine wrapped by the ExecutionEngine and trying
to get the DataLayout would break.

It seems tricky to solve the problem completely in the C API
implementation. This patch tries to address this backward
compatibility in a more lighter way in the C++ API. The C API is
restored in its original state and the removed C++ API is
reintroduced, but privately. The C API is friended to the
TargetMachine and should be the only consumer for this API.

Reviewers: ributzka

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

From: Mehdi Amini <mehdi.amini@apple.com>

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

[docs] Improvements to CMake.rst

- Fix some grammatical and typographical errors.
- Try to improve upon some awkward/nonstandard phrasings.
- Expand slightly the treatment of how you specify arguments to cmake.
- Update the list of possible LLVM_BUILD_TESTS and state where to find the
  definitive list.
- Correct the name of llvm-tblgen.
- Expand slightly the treatment of several build options, including
  LLVM_LIT_TOOLS_DIR, LLVM_ENABLE_FFI, and LLVM_EXTERNAL_project_SOURCE_DIR.

Patch by Brian R. Gaeke!

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

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

[PowerPC] PPCVSXFMAMutate should ignore trivial-copy addends

We might end up with a trivial copy as the addend, and if so, we should ignore
the corresponding FMA instruction. The trivial copy can be coalesced away later,
so there's nothing to do here. We should not, however, assert. Fixes PR24544.

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

Revert r245355 "Release script: correctly symlink clang-tools-extra into the build (PR22765)"

This worked with the CMake build but broke the Autoconf one.

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

Try to fix buildbots

Apparently std::vector::erase(const_iterator) (as opposed to the
non-const iterator) is a part of C++11 but it seems this is not available
on all the buildbots.

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

fix typos; NFC

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