[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 ...

Use a different block id for block of metadata kind records

Summary:
There are currently two blocks with the METADATA_BLOCK id at module
scope. The first has the module-level metadata values (consis

Use a different block id for block of metadata kind records

Summary:
There are currently two blocks with the METADATA_BLOCK id at module
scope. The first has the module-level metadata values (consisting of
some combination of METADATA_* record codes except for METADATA_KIND).
The second consists only of METADATA_KIND records. The latter is used
only in the METADATA_ATTACHMENT block within function blocks (for
metadata attached to instructions).

For ThinLTO we want to delay the parsing of module level metadata
until all functions have been imported from that module (there is some
bookkeeping used to suture it up when we read it during a post-pass).
However, we do need the METADATA_KIND records when parsing the function
body during importing, since those kinds are used as described above.

To simplify identification and parsing of just the block containing
the metadata kinds, use a different block id (METADATA_KIND_BLOCK_ID).
Support older bitcode without the new block id as well.

Reviewers: dexonsmith, joker.eph

Subscribers: davidxl, llvm-commits

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

llvm-svn: 253154

show more ...

use range-based for loop; NFCI

llvm-svn: 253048

[OperandBundles] Identify operand bundles with both their names and IDs

No code uses this functionality yet. This change just exposes
information / structure that was already present.

llvm-svn: 25

[OperandBundles] Identify operand bundles with both their names and IDs

No code uses this functionality yet. This change just exposes
information / structure that was already present.

llvm-svn: 252644

show more ...

[Bitcode] Add enums for call instruction markers and flags. NFC.

This commit adds enums in LLVMBitCodes.h to improve readability and
maintainability. This is a follow-up to r252368 which was discuss

[Bitcode] Add enums for call instruction markers and flags. NFC.

This commit adds enums in LLVMBitCodes.h to improve readability and
maintainability. This is a follow-up to r252368 which was discussed
here:

http://reviews.llvm.org/D12923

llvm-svn: 252395

show more ...

[OperandBundles] Rename accessor, NFC

Rename getOperandBundle to getOperandBundleAt since that's more obvious.

llvm-svn: 252388

Add 'notail' marker for call instructions.

This marker prevents optimization passes from adding 'tail' or
'musttail' markers to a call. Is is used to prevent tail call
optimization from being perfor

Add 'notail' marker for call instructions.

This marker prevents optimization passes from adding 'tail' or
'musttail' markers to a call. Is is used to prevent tail call
optimization from being performed on the call.

rdar://problem/22667622

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

llvm-svn: 252368

show more ...

Add a new attribute: norecurse

This attribute allows the compiler to assume that the function never recurses into itself, either directly or indirectly (transitively). This can be used among other t

Add a new attribute: norecurse

This attribute allows the compiler to assume that the function never recurses into itself, either directly or indirectly (transitively). This can be used among other things to demote global variables to locals.

llvm-svn: 252282

show more ...

DI: Reverse direction of subprogram -> function edge.

Previously, subprograms contained a metadata reference to the function they
described. Because most clients need to get or set a subprogram for

DI: Reverse direction of subprogram -> function edge.

Previously, subprograms contained a metadata reference to the function they
described. Because most clients need to get or set a subprogram for a given
function rather than the other way around, this created unneeded inefficiency.

For example, many passes needed to call the function llvm::makeSubprogramMap()
to build a mapping from functions to subprograms, and the IR linker needed to
fix up function references in a way that caused quadratic complexity in the IR
linking phase of LTO.

This change reverses the direction of the edge by storing the subprogram as
function-level metadata and removing DISubprogram's function field.

Since this is an IR change, a bitcode upgrade has been provided.

Fixes PR23367. An upgrade script for textual IR for out-of-tree clients is
attached to the PR.

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

llvm-svn: 252219

show more ...

Fix Abbrev emission in WriteIdentificationBlock

This Abbrev was not emitted and basically unused, just leacking there.

From: Mehdi Amini <[email protected]>
llvm-svn: 252110

Clang format a few prior patches (NFC)

I had clang formatted my earlier patches using the wrong style.
Reformatted with the LLVM style.

llvm-svn: 251812

Add an (optional) identification block in the bitcode

Processing bitcode from a different LLVM version can lead to
unexpected behavior. The LLVM project guarantees autoupdating
bitcode from a previo

Add an (optional) identification block in the bitcode

Processing bitcode from a different LLVM version can lead to
unexpected behavior. The LLVM project guarantees autoupdating
bitcode from a previous minor revision for the same major, but
can't make any promise when reading bitcode generated from a
either a non-released LLVM, a vendor toolchain, or a "future"
LLVM release. This patch aims at being more user-friendly and
allows a bitcode produce to emit an optional block at the
beginning of the bitcode that will contains an opaque string
intended to describe the bitcode producer information. The
bitcode reader will dump this information alongside any error it
reports.

The optional block also includes an "epoch" number, monotonically
increasing when incompatible changes are made to the bitcode. The
reader will reject bitcode whose epoch is different from the one
expected.

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

From: Mehdi Amini <[email protected]>
llvm-svn: 251325

show more ...

Pass FunctionInfoIndex by reference to WriteFunctionSummaryToFile (NFC)

Implemented suggestion by dblakie in review for r250704.

llvm-svn: 250723

BitcodeWriter: Stop using implicit ilist iterator conversion, NFC

Now LLVMBitWriter compiles without implicit ilist iterator conversions.

In these cases, the cleanest thing was to switch to range-b

BitcodeWriter: Stop using implicit ilist iterator conversion, NFC

Now LLVMBitWriter compiles without implicit ilist iterator conversions.

In these cases, the cleanest thing was to switch to range-based for
loops. Since there wasn't much noise I converted sub-loops and parent
loops as a drive-by.

llvm-svn: 250144

show more ...

Fix combined function index abbrev (NFC)

Removed an unused abbrev op in the VST_CODE_COMBINED_FNENTRY abbrev.

I noticed while writing/testing an array string dumper for
llvm-bcanalyze that the comb

Fix combined function index abbrev (NFC)

Removed an unused abbrev op in the VST_CODE_COMBINED_FNENTRY abbrev.

I noticed while writing/testing an array string dumper for
llvm-bcanalyze that the combined function's VST entry abbrevs contained
an old field that I am not using. Everything was working fine since the
bitcode writer and reader were in sync on how the record fields were
actually being set up and interpreted.

llvm-svn: 249691

show more ...

Support for function summary index bitcode sections and files.

Summary:
The bitcode format is described in this document:
https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view
For more

Support for function summary index bitcode sections and files.

Summary:
The bitcode format is described in this document:
https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view
For more info on ThinLTO see:
https://sites.google.com/site/llvmthinlto

The first customer is ThinLTO, however the data structures are designed
and named more generally based on prior feedback. There are a few
comments regarding how certain interfaces are used by ThinLTO, and the
options added here to gold currently have ThinLTO-specific names as the
behavior they provoke is currently ThinLTO-specific.

This patch includes support for generating per-module function indexes,
the combined index file via the gold plugin, and several tests
(more are included with the associated clang patch D11908).

Reviewers: dexonsmith, davidxl, joker.eph

Subscribers: llvm-commits

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

llvm-svn: 249270

show more ...

[Bitcode][Asm] Teach LLVM to read and write operand bundles.

Summary:
This also adds the first set of tests for operand bundles.

The optimizer has not been audited to ensure that it does the right

[Bitcode][Asm] Teach LLVM to read and write operand bundles.

Summary:
This also adds the first set of tests for operand bundles.

The optimizer has not been audited to ensure that it does the right
thing with operand bundles.

Depends on D12456.

Reviewers: reames, chandlerc, majnemer, dexonsmith, kmod, JosephTremoulet, rnk, bogner

Subscribers: maksfb, llvm-commits

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

llvm-svn: 248551

show more ...