Add getBlockProfileCount method to BlockFrequencyInfo

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

llvm-svn: 264179

[ThinLTO] Record all global variable defs in the summary

Record all variable defs with a summary record to aid in building a
complete reference graph and locating constant variable defs to import.

[ThinLTO] Record all global variable defs in the summary

Record all variable defs with a summary record to aid in building a
complete reference graph and locating constant variable defs to import.

llvm-svn: 263576

show more ...

BitcodeWriter dyn_cast cleanup for r263275 (NFC)

Address review suggestions from dblaikie: change a few dyn_cast to cast
and fold a cast into if condition.

llvm-svn: 263526

[ThinLTO] Renaming of function index to module summary index (NFC)

(Resubmitting after fixing missing file issue)

With the changes in r263275, there are now more than just functions in
the summary.

[ThinLTO] Renaming of function index to module summary index (NFC)

(Resubmitting after fixing missing file issue)

With the changes in r263275, there are now more than just functions in
the summary. Completed the renaming of data structures (started in
r263275) to reflect the wider scope. In particular, changed the
FunctionIndex* data structures to ModuleIndex*, and renamed related
variables and comments. Also renamed the files to reflect the changes.

A companion clang patch will immediately succeed this patch to reflect
this renaming.

llvm-svn: 263513

show more ...

Revert "[ThinLTO] Renaming of function index to module summary index (NFC)"

This reverts commit r263490. Missed a file.

llvm-svn: 263493

[ThinLTO] Renaming of function index to module summary index (NFC)

With the changes in r263275, there are now more than just functions in
the summary. Completed the renaming of data structures (star

[ThinLTO] Renaming of function index to module summary index (NFC)

With the changes in r263275, there are now more than just functions in
the summary. Completed the renaming of data structures (started in
r263275) to reflect the wider scope. In particular, changed the
FunctionIndex* data structures to ModuleIndex*, and renamed related
variables and comments. Also renamed the files to reflect the changes.

A companion clang patch will immediately succeed this patch to reflect
this renaming.

llvm-svn: 263490

show more ...

[Bitcode] Make writeComdats less strange

It had a weird artificial limitation on the write side: the comdat name
couldn't be bigger than 2**16. However, the reader had no such
limitation. Make the

[Bitcode] Make writeComdats less strange

It had a weird artificial limitation on the write side: the comdat name
couldn't be bigger than 2**16. However, the reader had no such
limitation. Make the reader and the writer agree.

llvm-svn: 263377

show more ...

[ThinLTO] Support for reference graph in per-module and combined summary.

Summary:
This patch adds support for including a full reference graph including
call graph edges and other GV references in

[ThinLTO] Support for reference graph in per-module and combined summary.

Summary:
This patch adds support for including a full reference graph including
call graph edges and other GV references in the summary.

The reference graph edges can be used to make importing decisions
without materializing any source modules, can be used in the plugin
to make file staging decisions for distributed build systems, and is
expected to have other uses.

The call graph edges are recorded in each function summary in the
bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO
data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when
there is PGO, where the ValueId can be mapped to the function GUID via
the ValueSymbolTable. In the function index in memory, the call graph
edges reference the target via the CalleeGUID instead of the
CalleeValueId.

The reference graph edges are recorded in each summary record with a
list of referenced value IDs, which can be mapped to value GUID via the
ValueSymbolTable.

Addtionally, a new summary record type is added to record references
from global variable initializers. A number of bitcode records and data
structures have been renamed to reflect the newly expanded scope of the
summary beyond functions. More cleanup will follow.

Reviewers: joker.eph, davidxl

Subscribers: joker.eph, llvm-commits

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

llvm-svn: 263275

show more ...

Bitcode writer: fix a typo, using getName() instead of getSourceFileName()

When emitting the source filename, the encoding of the string
was checked against the name instead of the filename.

From:

Bitcode writer: fix a typo, using getName() instead of getSourceFileName()

When emitting the source filename, the encoding of the string
was checked against the name instead of the filename.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 261019

show more ...

Restore "[ThinLTO] Use MD5 hash in function index." with fix

This restores commit r260408, along with a fix for a bot failure.

The bot failure was caused by dereferencing a unique_ptr in the same
c

Restore "[ThinLTO] Use MD5 hash in function index." with fix

This restores commit r260408, along with a fix for a bot failure.

The bot failure was caused by dereferencing a unique_ptr in the same
call instruction parameter list where it was passed via std::move.
Apparently due to luck this was not exposed when I built the compiler
with clang, only with gcc.

llvm-svn: 260442

show more ...

Revert "[ThinLTO] Use MD5 hash in function index." due to bot failure

This reverts commit r260408. Bot failure that I need to investigate.

llvm-svn: 260412

[ThinLTO] Use MD5 hash in function index.

Summary:
This patch uses the lower 64-bits of the MD5 hash of a function name as
a GUID in the function index, instead of storing function names. Any
local

[ThinLTO] Use MD5 hash in function index.

Summary:
This patch uses the lower 64-bits of the MD5 hash of a function name as
a GUID in the function index, instead of storing function names. Any
local functions are first given a global name by prepending the original
source file name. This is the same naming scheme and GUID used by PGO in
the indexed profile format.

This change has a couple of benefits. The primary benefit is size
reduction in the combined index file, for example 483.xalancbmk's
combined index file was reduced by around 70%. It should also result in
memory savings for the index file in memory, as the in-memory map is
also indexed by the hash instead of the string.

Second, this enables integration with indirect call promotion, since the
indirect call profile targets are recorded using the same global naming
convention and hash. This will enable the function importer to easily
locate function summaries for indirect call profile targets to enable
their import and subsequent promotion.

The original source file name is recorded in the bitcode in a new
module-level record for use in the ThinLTO backend pipeline.

Reviewers: davidxl, joker.eph

Subscribers: llvm-commits, joker.eph

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

llvm-svn: 260408

show more ...

Fix VST_CODE_* bitcode id comments (NFC)

llvm-svn: 260382

[ThinLTO] Include linkage type in function summary

Summary:
Adds the linkage type to both the per-module and combined function
summaries, which subsumes the current islocal bit. This will eventually

[ThinLTO] Include linkage type in function summary

Summary:
Adds the linkage type to both the per-module and combined function
summaries, which subsumes the current islocal bit. This will eventually
be used to optimized linkage types based on global summary-based
analysis.

Reviewers: joker.eph

Subscribers: joker.eph, davidxl, llvm-commits

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

llvm-svn: 259993

show more ...

[ThinLTO] Ensure function summary output order is stable

Iterate over the function list instead of a DenseMap of Function pointers
when emitting the function summary into the module.

This fixes PR2

[ThinLTO] Ensure function summary output order is stable

Iterate over the function list instead of a DenseMap of Function pointers
when emitting the function summary into the module.

This fixes PR26419.

llvm-svn: 259398

show more ...

[llvm-bcanalyzer] Dump bitcode wrapper header

This patch enables llvm-bcanalyzer to print the bitcode wrapper header
if the file has one, which is needed to test the changes made in
r258627 (bitcode

[llvm-bcanalyzer] Dump bitcode wrapper header

This patch enables llvm-bcanalyzer to print the bitcode wrapper header
if the file has one, which is needed to test the changes made in
r258627 (bitcode-wrapper-header-armv7m.ll is the test case for r258627).

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

llvm-svn: 259162

show more ...

[Bitcode] Insert the darwin wrapper at the beginning of a file when the
target is macho.

It looks like the check for macho was accidentally dropped in r132959.

I don't have a test case, but I'll ad

[Bitcode] Insert the darwin wrapper at the beginning of a file when the
target is macho.

It looks like the check for macho was accidentally dropped in r132959.

I don't have a test case, but I'll add one if anyone knows how this can
be tested.

llvm-svn: 258627

show more ...

NFC Test Commit whitespace change in a comment

Changed whitespace so comments line up.

llvm-svn: 258151

Bitcode: Fix reading and writing of ConstantDataVectors of halfs

In r254991 I allowed ConstantDataVectors to contain elements of
HalfTy, but I missed updating the bitcode reader and writer to handle

Bitcode: Fix reading and writing of ConstantDataVectors of halfs

In r254991 I allowed ConstantDataVectors to contain elements of
HalfTy, but I missed updating the bitcode reader and writer to handle
this, so now we crash if we try to emit bitcode on programs that have
constant vectors of half.

This fixes the issue and adds test coverage for reading and writing
constant sequences in bitcode.

llvm-svn: 256982

show more ...

Add InaccessibleMemOnly and inaccessibleMemOrArgMemOnly attributes

Summary:
This patch introduces two new function attributes

InaccessibleMemOnly: This attribute indicates that the function may on

Add InaccessibleMemOnly and inaccessibleMemOrArgMemOnly attributes

Summary:
This patch introduces two new function attributes

InaccessibleMemOnly: This attribute indicates that the function may only access memory that is not accessible by the program/IR being compiled. This is a weaker form of ReadNone.
inaccessibleMemOrArgMemOnly: This attribute indicates that the function may only access memory that is either not accessible by the program/IR being compiled, or is pointed to by its pointer arguments. This is a weaker form of ArgMemOnly

Test cases have been updated. This revision uses this (https://github.com/llvm-mirror/llvm/commit/d001932f3a8aa1ebd1555162fdce365f011bc292) as reference.

Reviewers: jmolloy, hfinkel

Subscribers: reames, joker.eph, llvm-commits

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

llvm-svn: 255778

show more ...

add fast-math-flags to 'call' instructions (PR21290)

This patch adds optional fast-math-flags (the same that apply to fmul/fadd/fsub/fdiv/frem/fcmp)
to call instructions in IR. Follow-up patches wou

add fast-math-flags to 'call' instructions (PR21290)

This patch adds optional fast-math-flags (the same that apply to fmul/fadd/fsub/fdiv/frem/fcmp)
to call instructions in IR. Follow-up patches would use these flags in LibCallSimplifier, add
support to clang, and extend FMF to the DAG for calls.

Motivating example:

%y = fmul fast float %x, %x
%z = tail call float @sqrtf(float %y)

We'd like to be able to optimize sqrt(x*x) into fabs(x). We do this today using a function-wide
attribute for unsafe-math, but we really want to trigger on the instructions themselves:

%z = tail call fast float @sqrtf(float %y)

because in an LTO build it's possible that calls with fast semantics have been inlined into a
function with non-fast semantics.

The code changes and tests are based on the recent commits that added "notail":
http://reviews.llvm.org/rL252368

and added FMF to fcmp:
http://reviews.llvm.org/rL241901

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

llvm-svn: 255555

show more ...

[IR] Remove terminatepad

It turns out that terminatepad gives little benefit over a cleanuppad
which calls the termination function. This is not sufficient to
implement fully generic filters but MS

[IR] Remove terminatepad

It turns out that terminatepad gives little benefit over a cleanuppad
which calls the termination function. This is not sufficient to
implement fully generic filters but MSVC doesn't support them which
makes terminatepad a little over-designed.

Depends on D15478.

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

llvm-svn: 255522

show more ...

[IR] Reformulate LLVM's EH funclet IR

While we have successfully implemented a funclet-oriented EH scheme on
top of LLVM IR, our scheme has some notable deficiencies:
- catchendpad and cleanupendpad

[IR] Reformulate LLVM's EH funclet IR

While we have successfully implemented a funclet-oriented EH scheme on
top of LLVM IR, our scheme has some notable deficiencies:
- catchendpad and cleanupendpad are necessary in the current design
but they are difficult to explain to others, even to seasoned LLVM
experts.
- catchendpad and cleanupendpad are optimization barriers. They cannot
be split and force all potentially throwing call-sites to be invokes.
This has a noticable effect on the quality of our code generation.
- catchpad, while similar in some aspects to invoke, is fairly awkward.
It is unsplittable, starts a funclet, and has control flow to other
funclets.
- The nesting relationship between funclets is currently a property of
control flow edges. Because of this, we are forced to carefully
analyze the flow graph to see if there might potentially exist illegal
nesting among funclets. While we have logic to clone funclets when
they are illegally nested, it would be nicer if we had a
representation which forbade them upfront.

Let's clean this up a bit by doing the following:
- Instead, make catchpad more like cleanuppad and landingpad: no control
flow, just a bunch of simple operands; catchpad would be splittable.
- Introduce catchswitch, a control flow instruction designed to model
the constraints of funclet oriented EH.
- Make funclet scoping explicit by having funclet instructions consume
the token produced by the funclet which contains them.
- Remove catchendpad and cleanupendpad. Their presence can be inferred
implicitly using coloring information.

N.B. The state numbering code for the CLR has been updated but the
veracity of it's output cannot be spoken for. An expert should take a
look to make sure the results are reasonable.

Reviewers: rnk, JosephTremoulet, andrew.w.kaylor

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

llvm-svn: 255422

show more ...

Macro debug info support in LLVM IR
Introduced DIMacro and DIMacroFile debug info metadata in the LLVM IR to support macros.

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

llvm-svn: 255245

[ThinLTO] Add MODULE_CODE_METADATA_VALUES record

Summary:
This is split out from the ThinLTO metadata mapping patch
http://reviews.llvm.org/D14752.

To avoid needing to parse the module level metada

[ThinLTO] Add MODULE_CODE_METADATA_VALUES record

Summary:
This is split out from the ThinLTO metadata mapping patch
http://reviews.llvm.org/D14752.

To avoid needing to parse the module level metadata during function
importing, a new module-level record is added which holds the
number of module-level metadata values. This is required because
metadata value ids are assigned implicitly during parsing, and the
function-level metadata ids start after the module-level metadata ids.

I made a change to this version of the code compared to D14752
in order to add more consistent and thorough assertion checking of the
new record value. We now unconditionally use the record value to
initialize the MDValueList size, and handle it the same in parseMetadata
for all module level metadata cases (lazy loading or not).

Reviewers: dexonsmith, joker.eph

Subscribers: davidxl, llvm-commits, joker.eph

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

llvm-svn: 253668

show more ...