Commit Graph

107056 Commits

Author SHA1 Message Date
Duncan P. N. Exon Smith
8db4ddb14a IR: Fix a missed case when threading OnlyIfReduced through ConstantExpr
In r216015 I missed propagating `OnlyIfReduced` through the inline
versions of `getGetElementPtr()` (I was relying on compile failures on
mismatches between the header and source signatures to get them all).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216023 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 21:18:21 +00:00
Duncan P. N. Exon Smith
13f5c5896d verify-uselistorder: Force -preserve-bc-use-list-order
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216022 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 21:08:27 +00:00
Juergen Ributzka
1d58f989d4 [FastISel][AArch64] Extend floating-point materialization test.
This adds the missing test that I promised for r215753 to test the
materialization of the floating-point value +0.0.

Related to <rdar://problem/18027157>.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216019 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 20:35:07 +00:00
Rafael Espindola
6825609779 fix the gcc build
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216018 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 20:06:25 +00:00
Lang Hames
3414e45ffa [MCJIT] Allow '$' characters in symbol names in RuntimeDyldChecker.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216017 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 20:04:45 +00:00
Duncan P. N. Exon Smith
b03916a88b IR: Fix ConstantExpr::replaceUsesOfWithOnConstant()
Change `ConstantExpr` to follow the model the other constants are using:
only malloc a replacement if it's going to be used.  This fixes a subtle
bug where if an API user had used `ConstantExpr::get()` already to
create the replacement but hadn't given it any users, we'd delete the
replacement.

This relies on r216015 to thread `OnlyIfReduced` through
`ConstantExpr::getWithOperands()`.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216016 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 20:03:35 +00:00
Duncan P. N. Exon Smith
e2215571e5 IR: Thread OnlyIfReduced through ConstantExpr::getWithOperands()
In order to change `ConstantExpr::replaceUsesOfWithOnConstant()` to work
like other constants (e.g., using `ConstantArray::getImpl()`), thread
`OnlyIfReduced` through as necessary.  When `OnlyIfReduced` is false,
there's no functionality change.  When it's true, if there's no constant
folding or type changes `nullptr` is returned instead of the new
constant.

`ConstantExpr::replaceUsesOfWithOnConstant()` will be updated to use the
"true" version in a follow-up commit.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216015 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 19:45:37 +00:00
Rafael Espindola
a96d94aa6e Fix the MSVC build.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216014 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 19:45:15 +00:00
Juergen Ributzka
06bb1ca1e0 Reapply [FastISel][AArch64] Add support for more addressing modes (r215597).
Note: This was originally reverted to track down a buildbot error. Reapply
without any modifications.

Original commit message:
FastISel didn't take much advantage of the different addressing modes available
to it on AArch64. This commit allows the ComputeAddress method to recognize more
addressing modes that allows shifts and sign-/zero-extensions to be folded into
the memory operation itself.

For Example:
  lsl x1, x1, #3     --> ldr x0, [x0, x1, lsl #3]
  ldr x0, [x0, x1]

  sxtw x1, w1
  lsl x1, x1, #3     --> ldr x0, [x0, x1, sxtw #3]
  ldr x0, [x0, x1]

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216013 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 19:44:17 +00:00
Juergen Ributzka
96b1e70c66 Reapply [FastISel][X86] Add large code model support for materializing floating-point constants (r215595).
Note: This was originally reverted to track down a buildbot error. Reapply
without any modifications.

Original commit message:
In the large code model for X86 floating-point constants are placed in the
constant pool and materialized by loading from it. Since the constant pool
could be far away, a PC relative load might not work. Therefore we first
materialize the address of the constant pool with a movabsq and then load
from there the floating-point value.

Fixes <rdar://problem/17674628>.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216012 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 19:44:13 +00:00
Juergen Ributzka
9c23685dd2 Reapply [FastISel][X86] Use XOR to materialize the "0" value (r215594).
Note: This was originally reverted to track down a buildbot error. Reapply
without any modifications.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216011 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 19:44:10 +00:00
Juergen Ributzka
e8757c5dbb Reapply [FastISel][X86] Emit more efficient instructions for integer constant materialization (r215593).
Note: This was originally reverted to track down a buildbot error. Reapply
without any modifications.

Original commit message:
This mostly affects the i64 value type, which always resulted in an 15byte
mobavsq instruction to materialize any constant. The custom code checks the
value of the immediate and tries to use a different and smaller mov
instruction when possible.

This fixes <rdar://problem/17420988>.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216010 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 19:44:06 +00:00
Juergen Ributzka
78f686d37c Reapply [FastISel][AArch64] Make use of the zero register when possible (r215591).
Note: This was originally reverted to track down a buildbot error. Reapply
without any modifications.

Original commit message:
This change materializes now the value "0" from the zero register.
The zero register can be folded by several instruction, so no
materialization is need at all.

Fixes <rdar://problem/17924413>.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216009 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 19:44:02 +00:00
Duncan P. N. Exon Smith
7d84c8ec54 ADT: Unit test for ArrayRef::equals change in r215986
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216008 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 19:18:46 +00:00
Duncan P. N. Exon Smith
bb69ce8c70 IR: De-duplicate code for replacing operands in place
This is non-trivial and sits in three places.  Move it to
ConstantUniqueMap.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216007 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 19:13:30 +00:00
Juergen Ributzka
f08cddcf56 Reapply [FastISel] Let the target decide first if it wants to materialize a constant (215588).
Note: This was originally reverted to track down a buildbot error. This commit
exposed a latent bug that was fixed in r215753. Therefore it is reapplied
without any modifications.

I run it through SPEC2k and SPEC2k6 for AArch64 and it didn't introduce any new
regeressions.

Original commit message:
This changes the order in which FastISel tries to materialize a constant.
Originally it would try to use a simple target-independent approach, which
can lead to the generation of inefficient code.

On X86 this would result in the use of movabsq to materialize any 64bit
integer constant - even for simple and small values such as 0 and 1. Also
some very funny floating-point materialization could be observed too.

On AArch64 it would materialize the constant 0 in a register even the
architecture has an actual "zero" register.

On ARM it would generate unnecessary mov instructions or not use mvn.

This change simply changes the order and always asks the target first if it
likes to materialize the constant. This doesn't fix all the issues
mentioned above, but it enables the targets to implement such
optimizations.

Related to <rdar://problem/17420988>.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216006 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 19:05:24 +00:00
Rafael Espindola
f2b844d0b1 Fix a pair of use after free. Should bring the bots back.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216005 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 18:59:14 +00:00
Rafael Espindola
548f2b6e8f Don't own the buffer in object::Binary.
Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries
(like Archive) and we had to create dummy buffers just to handle that. It is
also a bad fit for IRObjectFile where the Module wants to own the buffer too.

Keeping this ownership would make supporting IR inside native objects
particularly painful.

This patch focuses in lib/Object. If something elsewhere used to own an Binary,
now it also owns a MemoryBuffer.

This patch introduces a few new types.

* MemoryBufferRef. This is just a pair of StringRefs for the data and name.
  This is to MemoryBuffer as StringRef is to std::string.
* OwningBinary. A combination of Binary and a MemoryBuffer. This is needed
  for convenience functions that take a filename and return both the
  buffer and the Binary using that buffer.

The C api now uses OwningBinary to avoid any change in semantics. I will start
a new thread to see if we want to change it and how.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216002 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 18:44:46 +00:00
Alexey Samsonov
2ac376ba34 Hide two different AlignMode enums in anonymous namespaces. This bug is reported by UBSan.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216001 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 18:40:39 +00:00
Renato Golin
8308f0e30f Revert "Small refactor on VectorizerHint for deduplication"
This reverts commit r215994 because MSVC 2012 can't cope with its C++11 goodness.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215999 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 18:08:50 +00:00
Juergen Ributzka
8841fb5f25 [FastISel][AArch64] Fix a few BuildMI callsites where the result register was added as an operand register.
This fixes a few BuildMI callsites where the result register was added by
using addReg, which is per default a use and therefore an operand register.

Also use the zero register as result register when emitting a compare
instruction (SUBS with unused result register).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215997 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 17:41:53 +00:00
Renato Golin
dca126522d Small refactor on VectorizerHint for deduplication
Previously, the hint mechanism relied on clean up passes to remove redundant
metadata, which still showed up if running opt at low levels of optimization.
That also has shown that multiple nodes of the same type, but with different
values could still coexist, even if temporary, and cause confusion if the
next pass got the wrong value.

This patch makes sure that, if metadata already exists in a loop, the hint
mechanism will never append a new node, but always replace the existing one.
It also enhances the algorithm to cope with more metadata types in the future
by just adding a new type, not a lot of code.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215994 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 17:30:43 +00:00
Alex Lorenz
e3cea5fd9a Docs: add documentation for the coverage mapping format.
Differential Revision: http://reviews.llvm.org/D4729


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215990 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 17:05:58 +00:00
Rafael Espindola
9b29ff99c0 Modernize the .ll parsing interface.
* Use StringRef instead of std::string&
* Return a std::unique_ptr<Module> instead of taking an optional module to write
  to (was not really used).
* Use current comment style.
* Use current naming convention.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215989 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 16:58:54 +00:00
Duncan P. N. Exon Smith
2788345a9b CodingStandards: Document std::equal misbehaviour
I should have included this as part of r215986, which worked around this
corner by changing ArrayRef::equals() not to use std::equal.  Alas.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215988 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 16:49:40 +00:00
Duncan P. N. Exon Smith
7116af637c Reapply r215966, r215965, r215964, r215963, r215960, r215959, r215958, and r215957
This reverts commit r215981, which reverted the above commits because
MSVC std::equal asserts on nullptr iterators, and thes commits
introduced an `ArrayRef::equals()` on empty ArrayRefs.

ArrayRef was changed not to use std::equal in r215986.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215987 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 16:39:58 +00:00
Duncan P. N. Exon Smith
8c20a93bac ADT: Avoid using std::equal in ArrayRef::equals
MSVC's STL has a bug in `std::equal()`: it asserts on nullptr iterators,
causing a block revert in r215981.  This works around that by re-writing
`ArrayRef::equals()` to do the work itself.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215986 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 16:36:21 +00:00
Aaron Ballman
93710f07f0 Reverting r215966, r215965, r215964, r215963, r215960, r215959, r215958, and r215957 (these commits all rely on previous commits) due to build breakage. These commits cause failed assertions when testing Clang using MSVC 2013. The asserts are triggered from the std::equal call within ArrayRef::equals due to being passed invalid input (ArrayRef.begin() is returning a nullptr which is problematic).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215981 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 14:59:02 +00:00
Toma Tabacu
109447ff1b [mips] Add assembler support for .set arch=x directive.
Summary:
This directive is similar to ".set mipsX".
It is used to change the CPU target of the assembler, enabling it to accept instructions for a specific CPU.

This patch only implements the r4000 CPU (which is treated internally as generic mips3) and the generic ISAs.

Contains work done by Matheus Almeida.

Reviewers: dsanders

Reviewed By: dsanders

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215978 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 14:22:52 +00:00
Mayur Pandey
ecdb0ab90f InstCombine: ((A & ~B) ^ (~A & B)) to A ^ B
Proof using CVC3 follows:
$ cat t.cvc
A, B : BITVECTOR(32);
QUERY BVXOR((A & ~B),(~A & B)) = BVXOR(A,B);
$ cvc3 t.cvc
Valid.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215974 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 08:19:19 +00:00
Craig Topper
7ce4ac12fc Const-correct and prevent a copy of a SmallPtrSet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215973 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 07:44:27 +00:00
Craig Topper
25fc910167 Prevent use of the implicit copy constructor on SmallPtrSetImpl. An accidental copy caused my SmallPtrSet->SmallPtrSetImpl conversion commit to fail the other day.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215971 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 06:57:14 +00:00
Mayur Pandey
be63d58963 test commit (spelling correction)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215970 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 06:41:55 +00:00
Rafael Espindola
3f4ed32b43 Make it explicit that ExecutionEngine takes ownership of the modules.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215967 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 04:04:25 +00:00
Duncan P. N. Exon Smith
4d48c3f2a4 IR: Reduce RAUW traffic in ConstantVector
Avoid creating a new `ConstantVector` on an RAUW of one of its members.
This reduces RAUW traffic on any containing constant.

This is part of PR20515.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215966 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 02:24:46 +00:00
Duncan P. N. Exon Smith
3b666f3b59 IR: Fix ConstantArray::replaceUsesOfWithOnConstant()
Previously, `ConstantArray::replaceUsesOfWithOnConstant()` neglected to
check whether it becomes a `ConstantDataArray`.  Call
`ConstantArray::getImpl()` to check for that.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215965 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 02:21:00 +00:00
Duncan P. N. Exon Smith
6238162cc5 IR: Factor out replaceUsesOfWithOnConstantImpl(), NFC
Factor out common code, and take advantage of the new function to
add early returns to the callers.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215964 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 02:16:51 +00:00
Duncan P. N. Exon Smith
45d53fd4c4 IR: Split up Constant{Array,Vector}::get(), NFC
Introduce `getImpl()` that tries the simplification logic from `get()`
and then gives up.  This allows the logic to be reused elsewhere in a
follow-up commit.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215963 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 02:11:30 +00:00
Akira Hatanaka
6290308366 [X86, X87 stackifier] Do not mark an operand of a debug instruction as kill.
<rdar://problem/16952634>



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215962 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 02:09:57 +00:00
Duncan P. N. Exon Smith
1cfbb6358c IR: Reduce RAUW traffic in ConstantExpr
Avoid RAUW-ing `ConstantExpr` when an operand changes unless the new
`ConstantExpr` already has users.  This prevents the RAUW from rippling
up the expression tree unnecessarily.

This commit indirectly adds test coverage for r215953 (this is how I
came across the bug).

This is part of PR20515.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215960 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 01:12:53 +00:00
Duncan P. N. Exon Smith
fe0bf8fbf9 IR: Replace uses of ConstantAggrUniqueMap with ConstantUniqueMap
Now that `ConstantAggrUniqueMap` and `ConstantUniqueMap` work the same
way, change the aggregates to use the new one.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215959 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 01:02:18 +00:00
Duncan P. N. Exon Smith
f2534dd8b9 Remove extraneous typenames from r215957
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215958 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 00:55:34 +00:00
Duncan P. N. Exon Smith
78c0b35bf7 IR: Rewrite ConstantUniqueMap
Rewrite `ConstantUniqueMap` to be more similar to
`ConstantAggrUniqueMap`.

  - Use a `DenseMap` with custom MapInfo instead of a `std::map` with
    linear lookups and deletion.
  - Don't waste memory explicitly storing (heavyweight) keys.

Only `ConstantExpr` and `InlineAsm` actually use this data structure, so
I also updated them to use it.

This code cleanup is a precursor to reducing RAUW traffic on
`ConstantExpr` -- I felt badly adding a new (linear) call to
`ConstantUniqueMap::FindExistingKey`, so this designs away the concern.

A follow-up commit will transition the users of `ConstantAggrUniqueMap`
over.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215957 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 00:42:32 +00:00
Duncan P. N. Exon Smith
79f9f85c04 IR: Declare LookupKey right before its use, NFC
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215956 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 00:24:26 +00:00
Duncan P. N. Exon Smith
fd0a8133e5 IR: ArrayRef-ize {Insert,Extract}ValueConstantExpr constructors
No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215955 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 00:23:17 +00:00
Duncan P. N. Exon Smith
783d16f0b7 Prevent clang-format from moving the namespace closing brace, NFC
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215954 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 00:21:04 +00:00
Duncan P. N. Exon Smith
6b863256e4 NVPTX: Use RAUW instead of reinventing the wheel
This code had a homemade RAUW that was incorrect when a user was a
constant: instead of calling `replaceUsersWithOnConstant()` it would
incorrectly update the operand in-place, invalidating
`LLVMContextImpl::ExprConstants`.  RAUW does the job better.

The ValueHandle that `GVMap` is holding onto needs to be removed first,
so this commit also removes each variable from the map on-the-fly.

Since deletions from `ExprConstants` use a linear search that compares
directly on the pointer value (instead of using the key), there isn't an
obvious way to expose this with a testcase.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215953 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 00:20:02 +00:00
Duncan P. N. Exon Smith
165897841b LLParser: Handle BlockAddresses on-the-fly
Previously all `blockaddress()` constants were treated as forward
references.  They were resolved twice:  once at the end of the function
in question, and again at the end of the module.  Furthermore, if the
same blockaddress was referenced N times, the parser created N distinct
`GlobalVariable`s (one for each reference).

Instead, resolve all block addresses at the beginning of the function,
creating the standard `BasicBlock` forward references used for all other
basic block references.  After the function, all references can be
resolved immediately.  To check for the condition of parsing block
addresses from within the same function, I created a reference to the
current per-function-state in `BlockAddressPFS`.

Also, create only one forward-reference per basic block.  Because
forward references to block addresses are rare, the data structure here
shouldn't matter.  If somehow it does someday, this can be pretty easily
changed to a `DenseMap<std::pair<ValID, ValID>, GV>`.

This is part of PR20515.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215952 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 00:13:19 +00:00
Duncan P. N. Exon Smith
36c150801a verify-uselistorder: Call verifyModule() and improve output
Call `verifyModule()` after parsing and after every transformation.
Also convert some `DEBUG(dbgs())` to `errs()` to increase visibility
into what's going on.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215951 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-18 23:44:14 +00:00
Rafael Espindola
f359f7ef8c Use a range loop. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215948 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-18 23:15:59 +00:00