Commit Graph

1251 Commits

Author SHA1 Message Date
Rafael Espindola 2b7fef681f Delete more dead code.
Found by gcc 6.

llvm-svn: 273402
2016-06-22 12:44:16 +00:00
Peter Collingbourne 21521891a2 IR: Allow metadata attachments on declarations, and fix lazy loaded metadata issue with globals.
This change is motivated by an upcoming change to the metadata representation
used for CFI. The indirect function call checker needs type information for
external function declarations in order to correctly generate jump table
entries for such declarations. We currently associate such type information
with declarations using a global metadata node, but I plan [1] to move all
such metadata to global object attachments.

In bitcode, metadata attachments for function declarations appear in the
global metadata block. This seems reasonable to me because I expect metadata
attachments on declarations to be uncommon. In the long term I'd also expect
this to be the case for CFI, because we'd want to use some specialized bitcode
format for this metadata that could be read as part of the ThinLTO thin-link
phase, which would mean that it would not appear in the global metadata block.

To solve the lazy loaded metadata issue I was seeing with D20147, I use the
same bitcode representation for metadata attachments for global variables as I
do for function declarations. Since there's a use case for metadata attachments
in the global metadata block, we might as well use that representation for
global variables as well, at least until we have a mechanism for lazy loading
global variables.

In the assembly format, the metadata attachments appear after the "declare"
keyword in order to avoid a parsing ambiguity.

[1] http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html

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

llvm-svn: 273336
2016-06-21 23:42:48 +00:00
Benjamin Kramer 1afc1de406 Apply another batch of fixes from clang-tidy's performance-unnecessary-value-param.
Contains some manual fixes. No functionality change intended.

llvm-svn: 273047
2016-06-17 20:41:14 +00:00
Chandler Carruth 164a2aa6f4 [PM] Remove support for omitting the AnalysisManager argument to new
pass manager passes' `run` methods.

This removes a bunch of SFINAE goop from the pass manager and just
requires pass authors to accept `AnalysisManager<IRUnitT> &` as a dead
argument. This is a small price to pay for the simplicity of the system
as a whole, despite the noise that changing it causes at this stage.

This will also helpfull allow us to make the signature of the run
methods much more flexible for different kinds af passes to support
things like intelligently updating the pass's progression over IR units.

While this touches many, many, files, the changes are really boring.
Mostly made with the help of my trusty perl one liners.

Thanks to Sean and Hal for bouncing ideas for this with me in IRC.

llvm-svn: 272978
2016-06-17 00:11:01 +00:00
Peter Collingbourne 96efdd6107 IR: Introduce local_unnamed_addr attribute.
If a local_unnamed_addr attribute is attached to a global, the address
is known to be insignificant within the module. It is distinct from the
existing unnamed_addr attribute in that it only describes a local property
of the module rather than a global property of the symbol.

This attribute is intended to be used by the code generator and LTO to allow
the linker to decide whether the global needs to be in the symbol table. It is
possible to exclude a global from the symbol table if three things are true:
- This attribute is present on every instance of the global (which means that
  the normal rule that the global must have a unique address can be broken without
  being observable by the program by performing comparisons against the global's
  address)
- The global has linkonce_odr linkage (which means that each linkage unit must have
  its own copy of the global if it requires one, and the copy in each linkage unit
  must be the same)
- It is a constant or a function (which means that the program cannot observe that
  the unique-address rule has been broken by writing to the global)

Although this attribute could in principle be computed from the module
contents, LTO clients (i.e. linkers) will normally need to be able to compute
this property as part of symbol resolution, and it would be inefficient to
materialize every module just to compute it.

See:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html
for earlier discussion.

Part of the fix for PR27553.

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

llvm-svn: 272709
2016-06-14 21:01:22 +00:00
Duncan P. N. Exon Smith c3f8997386 BitcodeReader: Use std:::piecewise_construct when upgrading type refs
r267296 used std::piecewise_construct without using
std::forward_as_tuple, and r267298 hacked it out (using an emplace_back
followed by a couple of reset() calls) because of a problem on a bot.
I'm finally circling back to call forward_as_tuple as I should have to
begin with (thanks to David Blaikie for pointing out the missing piece).

Note that this code uses emplace_back() instead of
push_back(make_pair()) because the move constructor for TrackingMDRef is
expensive (cheaper than a copy, but still expensive).

llvm-svn: 272306
2016-06-09 20:46:33 +00:00
Reid Kleckner de3d8b500f [DebugInfo] Add calling convention support for DWARF and CodeView
Summary:
Now DISubroutineType has a 'cc' field which should be a DW_CC_ enum.  If
it is present and non-zero, the backend will emit it as a
DW_AT_calling_convention attribute. On the CodeView side, we translate
it to the appropriate enum for the LF_PROCEDURE record.

I added a new LLVM vendor specific enum to the list of DWARF calling
conventions. DWARF does not appear to attempt to standardize these, so I
assume it's OK to do this until we coordinate with GCC on how to emit
vectorcall convention functions.

Reviewers: dexonsmith, majnemer, aaboud, amccarth

Subscribers: mehdi_amini, llvm-commits

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

llvm-svn: 272197
2016-06-08 20:34:29 +00:00
Filipe Cabecinhas 6328f8e9e6 [BitCode] Make sure atomicrmw's argument is an actual PointerType
llvm-svn: 271851
2016-06-05 18:43:40 +00:00
Filipe Cabecinhas 036e73c8bf [BitCode] Make sure storeatomic's argument is an actual PointerType
llvm-svn: 271850
2016-06-05 18:43:33 +00:00
Filipe Cabecinhas fc2a3c98e9 [BitCode] Diagnose GEPs with no indices
llvm-svn: 271849
2016-06-05 18:43:26 +00:00
Filipe Cabecinhas 2849b48fea [BitCode] Don't allow constants of void type.
llvm-svn: 271848
2016-06-05 18:43:17 +00:00
Peter Collingbourne 382d81cacf IR: Allow multiple global metadata attachments with the same type.
This will be necessary to allow the global merge pass to attach
multiple debug info metadata nodes to global variables once we reverse
the edge from DIGlobalVariable to GlobalVariable.

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

llvm-svn: 271358
2016-06-01 01:17:57 +00:00
Peter Collingbourne cceae7feda Add support for metadata attachments for global variables.
This patch adds an IR, assembly and bitcode representation for metadata
attachments for globals. Future patches will port existing features to use
these new attachments.

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

llvm-svn: 271348
2016-05-31 23:01:54 +00:00
Benjamin Kramer 728f4448a9 Remove some 'const' specifiers that do nothing but prevent moving the argument.
Found by clang-tidy's misc-move-const-arg. While there drop some
obsolete c_str() calls.

llvm-svn: 271181
2016-05-29 10:46:35 +00:00
Benjamin Kramer 82de7d323d Apply clang-tidy's misc-move-constructor-init throughout LLVM.
No functionality change intended, maybe a tiny performance improvement.

llvm-svn: 270997
2016-05-27 14:27:24 +00:00
Manman Ren b5d7ff4fa3 Objective-C Class Properties: Autoupgrade "Class Properties" module flag.
When we have "Image Info Version" module flag but don't have "Class Properties"
module flag, set "Class Properties" module flag to 0, so we can correctly emit
errors when one module has the flag set and another module does not.

rdar://26469641

llvm-svn: 270791
2016-05-25 23:14:48 +00:00
Peter Collingbourne 4718f8b5f1 Add FIXMEs to all derived classes of std::error_category.
This helps make clear that we're moving away from std::error_code.

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

llvm-svn: 270604
2016-05-24 20:13:46 +00:00
Mehdi Amini fdbb8f47eb Avoid temporary vector for sorting in BitcodeWriter
As suggested by Duncan, fixup for r269634 and r269635

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 269715
2016-05-16 22:47:15 +00:00
Mehdi Amini 367577aab9 ThinLTO: fix non-determinism in bitcode writing
Calls are initialized from a DenseMap. We can sort them using the
value id to recover some determinism during serialization.

From: mehdi_amini <mehdi_amini@91177308-0d34-0410-b5e6-96231b3b80d8>
llvm-svn: 269638
2016-05-16 09:04:55 +00:00
Mehdi Amini fe97408495 Revert "ThinLTO: fix non-determinism in bitcode writing"
This reverts commit r269634, bots are broken.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 269637
2016-05-16 09:04:50 +00:00
Mehdi Amini f606c8d633 ThinLTO: fix another non-determinism in bitcode writing
GlobalVars Refs are initialized from a DenseSet. We can sort them
using the value id to recover some determinism during serialization.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 269635
2016-05-16 08:50:27 +00:00
Mehdi Amini 564c49a938 ThinLTO: fix non-determinism in bitcode writing
Calls are initialized from a DenseMap. We can sort them using the
value id to recover some determinism during serialization.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 269634
2016-05-16 08:50:23 +00:00
Mehdi Amini 7c9ceb5cc8 ThinLTO: fix non-determinism in bitcode writing
Refs are initialized from a DenseSet. We can sort them using the
value id to recover some determinism during serialization.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 269629
2016-05-16 04:50:47 +00:00
Benjamin Kramer a65b610bd2 Move helper classes into anonymous namespaces. NFC.
llvm-svn: 269591
2016-05-15 15:18:11 +00:00
Teresa Johnson e518c800f6 [ThinLTO] Fix Windows debug failure in new iterator
This fixes a debug assert on Windows from the new iterator
implementation added in r269059. The Windows std::vector iterator
operator== checks in debug mode that the containers being iterated over
are the same, which they may not be.

Fixed by checking that we are iterating over the same container before
comparing the container iterators.

llvm-svn: 269232
2016-05-11 20:46:22 +00:00
Teresa Johnson 84174c3771 Restore "[ThinLTO] Emit individual index files for distributed backends"
This restores commit r268627:
    Summary:
    When launching ThinLTO backends in a distributed build (currently
    supported in gold via the thinlto-index-only plugin option), emit
    an individual index file for each backend process as described here:
    http://lists.llvm.org/pipermail/llvm-dev/2016-April/098272.html

    ...

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

Address msan failures by avoiding std::prev on map.end(), the
theory is that this is causing issues due to some known UB problems
in __tree.

llvm-svn: 269059
2016-05-10 13:48:23 +00:00
Adrian Prantl 85338cbdb6 Implement a safer bitcode upgrade for DISubprogram.
The bitcode upgrade I added for DISubprogram in r266446 was based on the
assumption that the CU node for the subprogram was already materialized by the
time the DISubprogram is visited. This assumption may not hold true as future
versions of LLVM may decide to write out bitcode in a different order. This
patch corrects this by introducing a versioning bit next to the distinct flag to
unambiguously differentiate the new from the old record layouts.

Note for people stabilizing LLVM out-of-tree: This patch introduces a bitcode
incompatibility with llvm trunk revisions from r266446 — this commit. (But
D19987 will ensure that it degrades gracefully).

http://reviews.llvm.org/D20004
rdar://problem/26074194

llvm-svn: 268816
2016-05-06 22:53:06 +00:00
Peter Collingbourne 832e7fa579 BitcodeWriter: Simplify. NFC.
llvm-svn: 268707
2016-05-06 02:41:23 +00:00
Vitaly Buka 1df2338bb6 Revert "[ThinLTO] Emit individual index files for distributed backends"
MemorySanitizer: use-of-uninitialized-value in lib/Bitcode/Writer/BitcodeWriter.cpp:364:70
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/12544/steps/check-llvm%20msan/logs/stdio

This reverts commit 0c4a898ea550699d1b2f4fe3767251c8f9a48d52.

llvm-svn: 268660
2016-05-05 18:31:00 +00:00
Teresa Johnson 9254ebe3c0 [ThinLTO] Emit individual index files for distributed backends
Summary:
When launching ThinLTO backends in a distributed build (currently
supported in gold via the thinlto-index-only plugin option), emit
an individual index file for each backend process as described here:
http://lists.llvm.org/pipermail/llvm-dev/2016-April/098272.html

The individual index file encodes the summary and module information
required for implementing the importing/exporting decisions made
for a given module in the thin link step.
This is in place of the current mechanism that uses the combined index
to make importing decisions in each back end independently. It is an
enabler for doing global summary based optimizations in the thin link
step (which will be recorded in the individual index files), and reduces
the size of the index that must be sent to each backend process, and
the amount of work to scan it in the backends.

Rather than create entirely new ModuleSummaryIndex structures (and all
the included unique_ptrs) for each backend index file, a map is created
to record all of the GUID and summary pointers needed for a particular
index file. The IndexBitcodeWriter walks this map instead of the full
index (hiding the details of managing the appropriate summary iteration
in a new iterator subclass). This is more efficient than walking the
entire combined index and filtering out just the needed summaries during
each backend bitcode index write.

Depends on D19481.

Reviewers: joker.eph

Subscribers: llvm-commits, joker.eph

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

llvm-svn: 268627
2016-05-05 13:44:56 +00:00
Teresa Johnson 9e95da77f9 [ThinLTO] Remove missed piece of lazy summary reading support (NFC)
Missed in r267097.

llvm-svn: 268597
2016-05-05 02:30:48 +00:00
Sjoerd Meijer 41beee6575 Clean up to avoid compiler warnings for casting away const qualifiers.
Differential Revision: http://reviews.llvm.org/D19598

llvm-svn: 267753
2016-04-27 18:35:02 +00:00
Teresa Johnson 02e98331c0 [ThinLTO] Use valueid instead of bitcode offsets in combined index file
Summary:
With the removal of support for lazy parsing of combined index summary
records (e.g. r267344), we no longer need to include the summary record
bitcode offset in the VST entries for definitions. Change the combined
index format to be similar to the per-module index format in using value
ids to cross-reference from the summary record to the VST entry (rather
than the summary record bitcode offset to cross-reference in the other
direction).

The visible changes are:
1) Add the value id to the combined summary records
2) Remove the summary offset from the combined VST records, which has
the following effects:
- No longer need the VST_CODE_COMBINED_GVDEFENTRY record, as all
  combined index VST entries now only contain the value id and
  corresponding GUID.
- No longer have duplicate VST entries in the case where there are
  multiple definitions of a symbol (e.g. weak/linkonce), as they all
  have the same value id and GUID.

An implication of #2 above is that in order to hook up an alias to the
correct aliasee based on the value id of the aliasee recorded in the
combined index alias record, we need to scan the entries in the index
for that GUID to find the one from the same module (i.e. the case where
there are multiple entries for the aliasee). But the reader no longer
has to maintain a special map to hook up the alias/aliasee.

Reviewers: joker.eph

Subscribers: joker.eph, llvm-commits

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

llvm-svn: 267712
2016-04-27 13:28:35 +00:00
Duncan P. N. Exon Smith 03a04a58ea BitcodeReader: Delay metadata parsing until reading a function body
There's hardly any functionality change here.  Instead of calling
materializeMetadata on the first call to materialize(GlobalValue*), wait
until the first one that's actually going to do something.  Noticed by
inspection; I don't have a concrete case where this makes a difference.

Added an assertion in materializeMetadata to be sure this (or a future
change) doesn't delay materializeMetadata after function-level metadata.

llvm-svn: 267345
2016-04-24 15:04:28 +00:00
Teresa Johnson 28e457bccd [ThinLTO] Remove GlobalValueInfo class from index
Summary:
Remove the GlobalValueInfo and change the ModuleSummaryIndex to directly
reference summary objects. The info structure was there to support lazy
parsing of the combined index summary objects, which is no longer
needed and not supported.

Reviewers: joker.eph

Subscribers: joker.eph, llvm-commits

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

llvm-svn: 267344
2016-04-24 14:57:11 +00:00
Aaron Ballman c79c2be7d2 Silence two C4806 warnings ('|': unsafe operation: no value of type 'bool' promoted to type 'const unsigned int' can equal the given constant). The fact that they trigger with this code seems like it may be a bug, but the warning itself is still generally useful enough to retain it for now.
llvm-svn: 267337
2016-04-24 13:03:20 +00:00
Duncan P. N. Exon Smith 5892c6b94b BitcodeReader: Fix some holes in upgrade from r267296
Add tests for some missing cases to bitcode upgrade in r267296.

  - DICompositeType with an 'elements:' field, which will cause it to be
    involved in a cycle after the upgrade.

  - A DIDerivedType that references a class in 'extraData:'.

I updated test/Bitcode/dityperefs-3.8.ll with the missing cases and
regenerated test/Bitcode/dityperefs-3.8.ll.bc.

llvm-svn: 267332
2016-04-24 06:52:01 +00:00
Mehdi Amini ca2c54e04e Add "hasSection" flag in the Summary
Reviewers: tejohnson

Subscribers: llvm-commits

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

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267329
2016-04-24 05:31:43 +00:00
Mehdi Amini c3ed48c1bd Reorganize GlobalValueSummary with a "Flags" bitfield.
Right now it only contains the LinkageType, but will be extended
with "hasSection", "isOptSize", "hasInlineAssembly", etc.

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

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267319
2016-04-24 03:18:18 +00:00
Mehdi Amini 8fe6936e18 Add a version field in the bitcode for the summary
Differential Revision: http://reviews.llvm.org/D19456

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267318
2016-04-24 03:18:11 +00:00
Mehdi Amini ae64eafd31 Store and emit original name in combined index
Summary:
As discussed in D18298, some local globals can't
be renamed/promoted (because they have a section, or because
they are referenced from inline assembly).
To be able to detect naming collision, we need to keep around
the "GUID" using their original name without taking the linkage
into account.

Reviewers: tejohnson

Subscribers: joker.eph, llvm-commits

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

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267304
2016-04-23 23:38:17 +00:00
Duncan P. N. Exon Smith 69bdc8afa9 BitcodeReader: Avoid std::vector with non-movable types from r267296
r267298 didn't quite fix the build errors.  Use SmallVector instead of
std::vector, the latter of which I think is trying to maintain a strong
exception safety guarantee.

http://lab.llvm.org:8011/builders/lldb-amd64-ninja-freebsd11/builds/6228

llvm-svn: 267299
2016-04-23 21:36:59 +00:00
Duncan P. N. Exon Smith ece57ddd56 BitcodeReader: Avoid non-moving std::piecewise_construct from r267296
Not exactly sure why the host tries to use a copy constructor here, but
it's easy enough to work around it.

http://lab.llvm.org:8011/builders/lldb-amd64-ninja-freebsd11/builds/6227

llvm-svn: 267298
2016-04-23 21:23:41 +00:00
Duncan P. N. Exon Smith a59d3e5af8 DebugInfo: Remove MDString-based type references
Eliminate DITypeIdentifierMap and make DITypeRef a thin wrapper around
DIType*.  It is no longer legal to refer to a DICompositeType by its
'identifier:', and DIBuilder no longer retains all types with an
'identifier:' automatically.

Aside from the bitcode upgrade, this is mainly removing logic to resolve
an MDString-based reference to an actualy DIType.  The commits leading
up to this have made the implicit type map in DICompileUnit's
'retainedTypes:' field superfluous.

This does not remove DITypeRef, DIScopeRef, DINodeRef, and
DITypeRefArray, or stop using them in DI-related metadata.  Although as
of this commit they aren't serving a useful purpose, there are patchces
under review to reuse them for CodeView support.

The tests in LLVM were updated with deref-typerefs.sh, which is attached
to the thread "[RFC] Lazy-loading of debug info metadata":

  http://lists.llvm.org/pipermail/llvm-dev/2016-April/098318.html

llvm-svn: 267296
2016-04-23 21:08:00 +00:00
Duncan P. N. Exon Smith 30805b2417 BitcodeWriter: Emit uniqued subgraphs after all distinct nodes
Since forward references for uniqued node operands are expensive (and
those for distinct node operands are cheap due to
DistinctMDOperandPlaceholder), minimize forward references in uniqued
node operands.

Moreover, guarantee that when a cycle is broken by a distinct node, none
of the uniqued nodes have any forward references.  In
ValueEnumerator::EnumerateMetadata, enumerate uniqued node subgraphs
first, delaying distinct nodes until all uniqued nodes have been
handled.  This guarantees that uniqued nodes only have forward
references when there is a uniquing cycle (since r267276 changed
ValueEnumerator::organizeMetadata to partition distinct nodes in front
of uniqued nodes as a post-pass).

Note that a single uniqued subgraph can hit multiple distinct nodes at
its leaves.  Ideally these would themselves be emitted in post-order,
but this commit doesn't attempt that; I think it requires an extra pass
through the edges, which I'm not convinced is worth it (since
DistinctMDOperandPlaceholder makes forward references quite cheap
between distinct nodes).

I've added two testcases:

  - test/Bitcode/mdnodes-distinct-in-post-order.ll is just like
    test/Bitcode/mdnodes-in-post-order.ll, except with distinct nodes
    instead of uniqued ones.  This confirms that, in the absence of
    uniqued nodes, distinct nodes are still emitted in post-order.

  - test/Bitcode/mdnodes-distinct-nodes-break-cycles.ll is the minimal
    example where a naive post-order traversal would cause one uniqued
    node to forward-reference another.  IOW, it's the motivating test.

llvm-svn: 267278
2016-04-23 04:59:22 +00:00
Duncan P. N. Exon Smith 498b4977ba Avoid MSVC failure with default arguments in lambdas from r267270
http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/11700

llvm-svn: 267277
2016-04-23 04:52:47 +00:00
Duncan P. N. Exon Smith 1483fff271 BitcodeWriter: Emit distinct nodes before uniqued nodes
When an operand of a distinct node hasn't been read yet, the reader can
use a DistinctMDOperandPlaceholder.  This is much cheaper than forward
referencing from a uniqued node.  Change
ValueEnumerator::organizeMetadata to partition distinct nodes and
uniqued nodes to reduce the overhead of cycles broken by distinct nodes.

Mehdi measured this for me; this removes most of the RAUW from the
importing step of -flto=thin, even after a WIP patch that removes
string-based DITypeRefs (introducing many more cycles to the metadata
graph).

llvm-svn: 267276
2016-04-23 04:42:39 +00:00
Teresa Johnson c814e0c1fd Address comments.
llvm-svn: 267274
2016-04-23 04:31:20 +00:00
Teresa Johnson 37687f3911 Refactor bitcode writer into classes (NFC)
Summary:
As discussed in on the mailing list yesterday, I have refactored
BitcodeWriter.cpp to use classes to manage the bitcode writing process,
instead of passing around long lists of parameters between static
functions. See:
  http://lists.llvm.org/pipermail/llvm-dev/2016-April/098610.html

I created a parent BitcodeWriter class to own the BitstreamWriter,
write the header, and contain the main entry point into the writing
process. There are two derived classes, one for writing a module and one
for writing a combined index file (for ThinLTO), which manage the
writing process specific to those bitcode file types.

I also changed the functions to conform to LLVM coding standards
(lowercase function name first letter). The only two routines that still
start with an uppercase letter are the two external interfaces, which
can be fixed as a follow-on (I wanted to keep this round just within
BitcodeWriter.cpp).

Reviewers: dexonsmith, joker.eph

Subscribers: llvm-commits

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

llvm-svn: 267273
2016-04-23 04:30:47 +00:00
Duncan P. N. Exon Smith e9f85c482b Avoid ternery statement to please g++ after r267270, NFC
http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/36074

llvm-svn: 267272
2016-04-23 04:23:57 +00:00