Commit Graph

511 Commits

Author SHA1 Message Date
Sanjoy Das b9ca6dcc6b [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
2015-11-10 20:13:15 +00:00
Akira Hatanaka 97cb397132 [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
2015-11-07 02:48:49 +00:00
Sanjoy Das 54c3ca694a [OperandBundles] Rename accessor, NFC
Rename getOperandBundle to getOperandBundleAt since that's more obvious.

llvm-svn: 252388
2015-11-07 01:56:04 +00:00
Akira Hatanaka 5cfcce12eb 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
2015-11-06 23:55:38 +00:00
James Molloy e6f87ca812 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
2015-11-06 10:32:53 +00:00
Peter Collingbourne d4bff30370 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
2015-11-05 22:03:56 +00:00
Mehdi Amini ba19c6eed8 Fix Abbrev emission in WriteIdentificationBlock
This Abbrev was not emitted and basically unused, just leacking there.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 252110
2015-11-05 00:25:03 +00:00
Teresa Johnson f72278f051 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
2015-11-02 18:02:11 +00:00
Mehdi Amini 5d303285b9 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 <mehdi.amini@apple.com>
llvm-svn: 251325
2015-10-26 18:37:00 +00:00
Teresa Johnson 3da931f87a Pass FunctionInfoIndex by reference to WriteFunctionSummaryToFile (NFC)
Implemented suggestion by dblakie in review for r250704.

llvm-svn: 250723
2015-10-19 19:06:06 +00:00
Duncan P. N. Exon Smith 584af871cc 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
2015-10-13 03:26:19 +00:00
Teresa Johnson ca6b64ff04 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
2015-10-08 13:52:56 +00:00
Teresa Johnson 403a787e03 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
2015-10-04 14:33:43 +00:00
Sanjoy Das b513a9fa4f [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
2015-09-24 23:34:52 +00:00
David Blaikie 6a51dbdb3c [opaque pointer types] Add an explicit pointee type to alias records in the IR
Since aliases actually use and verify their explicit type already, no
further invalid testing is required here. The
invalid.test:ALIAS-TYPE-MISMATCH case catches errors due to emitting a
non-pointee type in the new format or a non-pointer type in the old
format.

llvm-svn: 247952
2015-09-17 22:18:59 +00:00
Teresa Johnson ff642b9b84 Restore "Function bitcode index in Value Symbol Table and lazy reading support"
This reverts commit r247898 (which reverted r247894).

Patch fixed to address two issues exposed by buildbots:
- unused variable warning in NDEBUG mode
- std::initializer_list lifetime issue causing test failures

Original Summary:
Support for including the function bitcode indices in the Value Symbol
Table. This requires writing the VST after the function blocks, which in
turn requires a new VST forward declaration record encoding the offset of
the full VST (which is backpatched to contain the offset after the VST
is written).

This patch also enables the lazy function reader to use the new function
indices out of the VST. This support will be used by ThinLTO as well, which
will be in a follow on patch. Backwards compatibility with older bitcode
files is maintained.

A new test is also included.

The bitcode format (used for the lazy reader as well as the upcoming
ThinLTO patches) came out of discussions with Duncan and others and is
described here:
https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view

Reviewers: dexonsmith, davidxl, joker.eph

Subscribers: llvm-commits

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

llvm-svn: 247927
2015-09-17 20:12:00 +00:00
Teresa Johnson 2e98d57ad4 Revert "Function bitcode index in Value Symbol Table and lazy reading support"
Temporarily revert to fix some buildbot issues. One is a minor issue
with a variable unused in NDEBUG mode. More concerning are some test
failures on win7 that I need to dig into.

This reverts commit 4e66a74543459832cfd571db42b4543580ae1d1d.

llvm-svn: 247898
2015-09-17 16:19:10 +00:00
Teresa Johnson b77b1f8a0c Function bitcode index in Value Symbol Table and lazy reading support
Summary:
Support for including the function bitcode indices in the Value Symbol
Table. This requires writing the VST after the function blocks, which in
turn requires a new VST forward declaration record encoding the offset of
the full VST (which is backpatched to contain the offset after the VST
is written).

This patch also enables the lazy function reader to use the new function
indices out of the VST. This support will be used by ThinLTO as well, which
will be in a follow on patch. Backwards compatibility with older bitcode
files is maintained.

A new test is also included.

The bitcode format (used for the lazy reader as well as the upcoming
ThinLTO patches) came out of discussions with Duncan and others and is
described here:
https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view

Reviewers: dexonsmith, davidxl, joker.eph

Subscribers: llvm-commits

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

llvm-svn: 247894
2015-09-17 15:52:30 +00:00
Teresa Johnson c01e4cbccc Refactor string encoding checks in BitcodeWriter (NFC)
llvm-svn: 247891
2015-09-17 14:37:35 +00:00
Joseph Tremoulet 9ce71f76b9 [WinEH] Add cleanupendpad instruction
Summary:
Add a `cleanupendpad` instruction, used to mark exceptional exits out of
cleanups (for languages/targets that can abort a cleanup with another
exception).  The `cleanupendpad` instruction is similar to the `catchendpad`
instruction in that it is an EH pad which is the target of unwind edges in
the handler and which itself has an unwind edge to the next EH action.
The `cleanupendpad` instruction, similar to `cleanupret` has a `cleanuppad`
argument indicating which cleanup it exits.  The unwind successors of a
`cleanuppad`'s `cleanupendpad`s must agree with each other and with its
`cleanupret`s.

Update WinEHPrepare (and docs/tests) to accomodate `cleanupendpad`.

Reviewers: rnk, andrew.w.kaylor, majnemer

Subscribers: llvm-commits

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

llvm-svn: 246751
2015-09-03 09:09:43 +00:00
Joseph Tremoulet 8220bcc570 [WinEH] Require token linkage in EH pad/ret signatures
Summary:
WinEHPrepare is going to require that cleanuppad and catchpad produce values
of token type which are consumed by any cleanupret or catchret exiting the
pad.  This change updates the signatures of those operators to require/enforce
that the type produced by the pads is token type and that the rets have an
appropriate argument.

The catchpad argument of a `CatchReturnInst` must be a `CatchPadInst` (and
similarly for `CleanupReturnInst`/`CleanupPadInst`).  To accommodate that
restriction, this change adds a notion of an operator constraint to both
LLParser and BitcodeReader, allowing appropriate sentinels to be constructed
for forward references and appropriate error messages to be emitted for
illegal inputs.

Also add a verifier rule (noted in LangRef) that a catchpad with a catchpad
predecessor must have no other predecessors; this ensures that WinEHPrepare
will see the expected linear relationship between sibling catches on the
same try.

Lastly, remove some superfluous/vestigial casts from instruction operand
setters operating on BasicBlocks.

Reviewers: rnk, majnemer

Subscribers: llvm-commits

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

llvm-svn: 245797
2015-08-23 00:26:33 +00:00
David Majnemer 0bc0eef71c [IR] Give catchret an optional 'return value' operand
Some personality routines require funclet exit points to be clearly
marked, this is done by producing a token at the funclet pad and
consuming it at the corresponding ret instruction.  CleanupReturnInst
already had a spot for this operand but CatchReturnInst did not.
Other personality routines don't need to use this which is why it has
been made optional.

llvm-svn: 245149
2015-08-15 02:46:08 +00:00
David Majnemer b611e3f50e [IR] Add token types
This introduces the basic functionality to support "token types".
The motivation stems from the need to perform operations on a Value
whose provenance cannot be obscured.

There are several applications for such a type but my immediate
motivation stems from WinEH.  Our personality routine enforces a
single-entry - single-exit regime for cleanups.  After several rounds of
optimizations, we may be left with a terminator whose "cleanup-entry
block" is not entirely clear because control flow has merged two
cleanups together.  We have experimented with using labels as operands
inside of instructions which are not terminators to indicate where we
came from but found that LLVM does not expect such exotic uses of
BasicBlocks.

Instead, we can use this new type to clearly associate the "entry point"
and "exit point" of our cleanup.  This is done by having the cleanuppad
yield a Token and consuming it at the cleanupret.
The token type makes it impossible to obscure or otherwise hide the
Value, making it trivial to track the relationship between the two
points.

What is the burden to the optimizer?  Well, it turns out we have already
paid down this cost by accepting that there are certain calls that we
are not permitted to duplicate, optimizations have to watch out for
such instructions anyway.  There are additional places in the optimizer
that we will probably have to update but early examination has given me
the impression that this will not be heroic.

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

llvm-svn: 245029
2015-08-14 05:09:07 +00:00
Yaron Keren 001e2e4228 Rangify for loop, NFC.
llvm-svn: 244434
2015-08-10 07:04:29 +00:00
Duncan P. N. Exon Smith 55ca964e94 DI: Disallow uniquable DICompileUnits
Since r241097, `DIBuilder` has only created distinct `DICompileUnit`s.
The backend is liable to start relying on that (if it hasn't already),
so make uniquable `DICompileUnit`s illegal and automatically upgrade old
bitcode.  This is a nice cleanup, since we can remove an unnecessary
`DenseSet` (and the associated uniquing info) from `LLVMContextImpl`.

Almost all the testcases were updated with this script:

    git grep -e '= !DICompileUnit' -l -- test |
    grep -v test/Bitcode |
    xargs sed -i '' -e 's,= !DICompileUnit,= distinct !DICompileUnit,'

I imagine something similar should work for out-of-tree testcases.

llvm-svn: 243885
2015-08-03 17:26:41 +00:00
Duncan P. N. Exon Smith ed013cd221 DI: Remove DW_TAG_arg_variable and DW_TAG_auto_variable
Remove the fake `DW_TAG_auto_variable` and `DW_TAG_arg_variable` tags,
using `DW_TAG_variable` in their place Stop exposing the `tag:` field at
all in the assembly format for `DILocalVariable`.

Most of the testcase updates were generated by the following sed script:

    find test/ -name "*.ll" -o -name "*.mir" |
    xargs grep -l 'DILocalVariable' |
    xargs sed -i '' \
      -e 's/tag: DW_TAG_arg_variable, //' \
      -e 's/tag: DW_TAG_auto_variable, //'

There were only a handful of tests in `test/Assembly` that I needed to
update by hand.

(Note: a follow-up could change `DILocalVariable::DILocalVariable()` to
set the tag to `DW_TAG_formal_parameter` instead of `DW_TAG_variable`
(as appropriate), instead of having that logic magically in the backend
in `DbgVariable`.  I've added a FIXME to that effect.)

llvm-svn: 243774
2015-07-31 18:58:39 +00:00
David Majnemer 654e130b6e New EH representation for MSVC compatibility
This introduces new instructions neccessary to implement MSVC-compatible
exception handling support.  Most of the middle-end and none of the
back-end haven't been audited or updated to take them into account.

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

llvm-svn: 243766
2015-07-31 17:58:14 +00:00
Bob Wilson 043ee65ef3 Reserve some constant values for the Swift calling convention.
Swift has a custom calling convention that also requires some new flags
on arguments and one new attribute on alloca instructions. This patch
does not include the implementation of that calling convention - that
will be provided as part of the open-source release of Swift; this only
reserves the bitcode constant values so that they are not used for
other purposes.

llvm-svn: 243379
2015-07-28 04:05:45 +00:00
Igor Laevsky 39d662f7ba Add argmemonly attribute.
This change adds new attribute called "argmemonly". Function marked with this attribute can only access memory through it's argument pointers. This attribute directly corresponds to the "OnlyAccessesArgumentPointees" ModRef behaviour in alias analysis.

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

llvm-svn: 241979
2015-07-11 10:30:36 +00:00
James Molloy 88eb535b2d Add support for fast-math flags to the FCmp instruction.
FCmp behaves a lot like a floating-point binary operator in many ways,
and can benefit from fast-math information. Flags such as nsz and nnan
can affect if this fcmp (in combination with a select) can be treated
as a fminnum/fmaxnum operation.

This adds backwards-compatible bitcode support, IR parsing and writing,
LangRef changes and IRBuilder changes. I'll need to audit InstSimplify
and InstCombine in a followup to find places where flags should be
copied.

llvm-svn: 241901
2015-07-10 12:52:00 +00:00
David Majnemer db82d2f338 Revert the new EH instructions
This reverts commits r241888-r241891, I didn't mean to commit them.

llvm-svn: 241893
2015-07-10 07:15:17 +00:00
David Majnemer ae2ffc8a8c New EH representation for MSVC compatibility
Summary:
This introduces new instructions neccessary to implement MSVC-compatible
exception handling support.  Most of the middle-end and none of the
back-end haven't been audited or updated to take them into account.

Reviewers: rnk, JosephTremoulet, reames, nlewycky, rjmccall

Subscribers: llvm-commits

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

llvm-svn: 241888
2015-07-10 07:00:44 +00:00
Adrian Prantl ab1243fe6c Add a DIModule metadata node to the IR.
It is meant to be used to record modules @imported by the current
compile unit, so a debugger an import the same modules to replicate this
environment before dropping into the expression evaluator.

DIModule is a sibling to DINamespace and behaves quite similarly.
In addition to the name of the module it also records the module
configuration details that are necessary to uniquely identify the module.
This includes the configuration macros (e.g., -DNDEBUG), the include path
where the module.map file is to be found, and the isysroot.

The idea is that the backend will turn this into a DW_TAG_module.

http://reviews.llvm.org/D9614
rdar://problem/20965932

llvm-svn: 241017
2015-06-29 23:03:47 +00:00
Pete Cooper 125ad17fed Use foreach loop over constant operands. NFC.
A number of places had explicit loops over Constant::operands().
Just use foreach loops where possible.

llvm-svn: 240694
2015-06-25 20:51:38 +00:00
Benjamin Kramer 5014f40fa6 [Bitcode] Replace hand-coded little endian handling with Endian.h functions.
No functional change intended.

llvm-svn: 239944
2015-06-17 20:55:30 +00:00
David Majnemer 7fddeccb8b Move the personality function from LandingPadInst to Function
The personality routine currently lives in the LandingPadInst.

This isn't desirable because:
- All LandingPadInsts in the same function must have the same
  personality routine.  This means that each LandingPadInst beyond the
  first has an operand which produces no additional information.

- There is ongoing work to introduce EH IR constructs other than
  LandingPadInst.  Moving the personality routine off of any one
  particular Instruction and onto the parent function seems a lot better
  than have N different places a personality function can sneak onto an
  exceptional function.

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

llvm-svn: 239940
2015-06-17 20:52:32 +00:00
Peter Collingbourne 82437bf7a5 Protection against stack-based memory corruption errors using SafeStack
This patch adds the safe stack instrumentation pass to LLVM, which separates
the program stack into a safe stack, which stores return addresses, register
spills, and local variables that are statically verified to be accessed
in a safe way, and the unsafe stack, which stores everything else. Such
separation makes it much harder for an attacker to corrupt objects on the
safe stack, including function pointers stored in spilled registers and
return addresses. You can find more information about the safe stack, as
well as other parts of or control-flow hijack protection technique in our
OSDI paper on code-pointer integrity (http://dslab.epfl.ch/pubs/cpi.pdf)
and our project website (http://levee.epfl.ch).

The overhead of our implementation of the safe stack is very close to zero
(0.01% on the Phoronix benchmarks). This is lower than the overhead of
stack cookies, which are supported by LLVM and are commonly used today,
yet the security guarantees of the safe stack are strictly stronger than
stack cookies. In some cases, the safe stack improves performance due to
better cache locality.

Our current implementation of the safe stack is stable and robust, we
used it to recompile multiple projects on Linux including Chromium, and
we also recompiled the entire FreeBSD user-space system and more than 100
packages. We ran unit tests on the FreeBSD system and many of the packages
and observed no errors caused by the safe stack. The safe stack is also fully
binary compatible with non-instrumented code and can be applied to parts of
a program selectively.

This patch is our implementation of the safe stack on top of LLVM. The
patches make the following changes:

- Add the safestack function attribute, similar to the ssp, sspstrong and
  sspreq attributes.

- Add the SafeStack instrumentation pass that applies the safe stack to all
  functions that have the safestack attribute. This pass moves all unsafe local
  variables to the unsafe stack with a separate stack pointer, whereas all
  safe variables remain on the regular stack that is managed by LLVM as usual.

- Invoke the pass as the last stage before code generation (at the same time
  the existing cookie-based stack protector pass is invoked).

- Add unit tests for the safe stack.

Original patch by Volodymyr Kuznetsov and others at the Dependable Systems
Lab at EPFL; updates and upstreaming by myself.

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

llvm-svn: 239761
2015-06-15 21:07:11 +00:00
Owen Anderson 85fa7d5037 Add initial support for the convergent attribute.
llvm-svn: 238264
2015-05-26 23:48:40 +00:00
Adrian Prantl 1f599f9f65 IR / debug info: Add a DWOId field to DICompileUnit,
so DWARF skeleton CUs can be expression in IR. A skeleton CU is a
(typically empty) DW_TAG_compile_unit that has a DW_AT_(GNU)_dwo_name and
a DW_AT_(GNU)_dwo_id attribute. It is used to refer to external debug info.

This is a prerequisite for clang module debugging as discussed in
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-November/040076.html.
In order to refer to external types stored in split DWARF (dwo) objects,
such as clang modules, we need to emit skeleton CUs, which identify the
dwarf object (i.e., the clang module) by filename (the SplitDebugFilename)
and a hash value, the dwo_id.

This patch only contains the IR changes. The idea is that a CUs with a
non-zero dwo_id field will be emitted together with a DW_AT_GNU_dwo_name
and DW_AT_GNU_dwo_id attribute.

http://reviews.llvm.org/D9488
rdar://problem/20091852

llvm-svn: 237949
2015-05-21 20:37:30 +00:00
Duncan P. N. Exon Smith 538ef562bd Bitcode: Set LastDL after writing DebugLocs
Somehow I dropped this in r233585, and we haven't had `DEBUG_LOC_AGAIN`
records since.  Add it back.  Also tests that the output assembly looks
okay.

Fixes PR23436.

llvm-svn: 236661
2015-05-06 22:51:12 +00:00
Duncan P. N. Exon Smith a9308c49ef IR: Give 'DI' prefix to debug info metadata
Finish off PR23080 by renaming the debug info IR constructs from `MD*`
to `DI*`.  The last of the `DIDescriptor` classes were deleted in
r235356, and the last of the related typedefs removed in r235413, so
this has all baked for about a week.

Note: If you have out-of-tree code (like a frontend), I recommend that
you get everything compiling and tests passing with the *previous*
commit before updating to this one.  It'll be easier to keep track of
what code is using the `DIDescriptor` hierarchy and what you've already
updated, and I think you're extremely unlikely to insert bugs.  YMMV of
course.

Back to *this* commit: I did this using the rename-md-di-nodes.sh
upgrade script I've attached to PR23080 (both code and testcases) and
filtered through clang-format-diff.py.  I edited the tests for
test/Assembler/invalid-generic-debug-node-*.ll by hand since the columns
were off-by-three.  It should work on your out-of-tree testcases (and
code, if you've followed the advice in the previous paragraph).

Some of the tests are in badly named files now (e.g.,
test/Assembler/invalid-mdcompositetype-missing-tag.ll should be
'dicompositetype'); I'll come back and move the files in a follow-up
commit.

llvm-svn: 236120
2015-04-29 16:38:44 +00:00
David Blaikie bdb4910202 [opaque pointer type] Encode the allocated type of an alloca rather than its pointer result type.
llvm-svn: 235998
2015-04-28 16:51:01 +00:00
David Blaikie 2a661cd062 [opaque pointer type] Encode the pointee type in the bitcode for 'cmpxchg'
As a space optimization, this instruction would just encode the pointer
type of the first operand and use the knowledge that the second and
third operands would be of the pointee type of the first. When typed
pointers go away, this assumption will no longer be available - so
encode the type of the second operand explicitly and rely on that for
the third.

Test case added to demonstrate the backwards compatibility concern,
which only comes up when the definition of the second operand comes
after the use (hence the weird basic block sequence) - at which point
the type needs to be explicitly encoded in the bitcode and the record
length changes to accommodate this.

llvm-svn: 235966
2015-04-28 04:30:29 +00:00
David Blaikie 1a848da518 [opaque pointer type] encode the pointee type of global variables
Use a few extra bits in the const field (after widening it from a fixed
single bit) to stash the address space which is no longer provided by
the type (and an extra bit in there to specify that we're using that new
encoding).

llvm-svn: 235911
2015-04-27 19:58:56 +00:00
Duncan P. N. Exon Smith 3d4cd756b6 IR: Add assembly/bitcode support for function metadata attachments
Add serialization support for function metadata attachments (added in
r235783).  The syntax is:

    define @foo() !attach !0 {

Metadata attachments are only allowed on functions with bodies.  Since
they come before the `{`, they're not really part of the body; since
they require a body, they're not really part of the header.  In
`LLParser` I gave them a separate function called from `ParseDefine()`,
`ParseOptionalFunctionMetadata()`.

In bitcode, I'm using the same `METADATA_ATTACHMENT` record used by
instructions.  Instruction metadata attachments are included in a
special "attachment" block at the end of a `Function`.  The attachment
records are laid out like this:

    InstID (KindID MetadataID)+

Note that these records always have an odd number of fields.  The new
code takes advantage of this to recognize function attachments (which
don't need an instruction ID):

    (KindID MetadataID)+

This means we can use the same attachment block already used for
instructions.

This is part of PR23340.

llvm-svn: 235785
2015-04-24 22:04:41 +00:00
David Blaikie 5ea1f7b744 [opaque pointer type] bitcode: add explicit callee type to invoke instructions
llvm-svn: 235735
2015-04-24 18:06:06 +00:00
David Blaikie 612ddbfde0 [opaque pointer types] Serialize the value type for store instructions
Without pointee types the space optimization of storing only the pointer
type and not the value type won't be viable - so add the extra type
information that would be missing.

Storeatomic coming soon.

llvm-svn: 235474
2015-04-22 04:14:42 +00:00
David Blaikie 561a157233 [opaque pointer type] Serialize the type of an llvm::Function as a function type rather than a function pointer type
llvm-svn: 235200
2015-04-17 16:28:26 +00:00
David Blaikie dbe6e0f171 [opaque pointer type] Explicit pointee type for call instruction
Use an extra bit in the CCInfo to flag the newer version of the
instructiont hat includes the type explicitly.

Tested the newer error cases I added, but didn't add tests for the finer
granularity improvements to existing error paths.

llvm-svn: 235160
2015-04-17 06:40:14 +00:00
Sanjoy Das 31ea6d1590 [IR] Introduce a dereferenceable_or_null(N) attribute.
Summary:
If a pointer is marked as dereferenceable_or_null(N), LLVM assumes it
is either `null` or `dereferenceable(N)` or both.  This change only
introduces the attribute and adds a token test case for the `llvm-as`
/ `llvm-dis`.  It does not hook up other parts of the optimizer to
actually exploit the attribute -- those changes will come later.

For pointers in address space 0, `dereferenceable(N)` is now exactly
equivalent to `dereferenceable_or_null(N)` && `nonnull`.  For other
address spaces, `dereferenceable(N)` is potentially weaker than
`dereferenceable_or_null(N)` && `nonnull` (since we could have a null
`dereferenceable(N)` pointer).

The motivating case for this change is Java (and other managed
languages), where pointers are either `null` or dereferenceable up to
some usually known-at-compile-time constant offset.

Reviewers: rafael, hfinkel

Reviewed By: hfinkel

Subscribers: nicholas, llvm-commits

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

llvm-svn: 235132
2015-04-16 20:29:50 +00:00
Duncan P. N. Exon Smith 62e0f454a0 DebugInfo: Remove 'inlinedAt:' field from MDLocalVariable
Remove 'inlinedAt:' from MDLocalVariable.  Besides saving some memory
(variables with it seem to be single largest `Metadata` contributer to
memory usage right now in -g -flto builds), this stops optimization and
backend passes from having to change local variables.

The 'inlinedAt:' field was used by the backend in two ways:

 1. To tell the backend whether and into what a variable was inlined.
 2. To create a unique id for each inlined variable.

Instead, rely on the 'inlinedAt:' field of the intrinsic's `!dbg`
attachment, and change the DWARF backend to use a typedef called
`InlinedVariable` which is `std::pair<MDLocalVariable*, MDLocation*>`.
This `DebugLoc` is already passed reliably through the backend (as
verified by r234021).

This commit removes the check from r234021, but I added a new check
(that will survive) in r235048, and changed the `DIBuilder` API in
r235041 to require a `!dbg` attachment whose 'scope:` is in the same
`MDSubprogram` as the variable's.

If this breaks your out-of-tree testcases, perhaps the script I used
(mdlocalvariable-drop-inlinedat.sh) will help; I'll attach it to PR22778
in a moment.

llvm-svn: 235050
2015-04-15 22:29:27 +00:00
Duncan P. N. Exon Smith a052ed6381 uselistorder: Pull the bit through WriteToBitcodFile()
Change the callers of `WriteToBitcodeFile()` to pass `true` or
`shouldPreserveBitcodeUseListOrder()` explicitly.  I left the callers
that want to send `false` alone.

I'll keep pushing the bit higher until hopefully I can delete the global
`cl::opt` entirely.

llvm-svn: 234957
2015-04-15 00:10:50 +00:00
Duncan P. N. Exon Smith 458593a457 uselistorder: Thread bit through ValueEnumerator
Canonicalize access to whether to preserve use-list order in bitcode on
a `bool` stored in `ValueEnumerator`.  Next step, expose this as a
`bool` through `WriteBitcodeToFile()`.

llvm-svn: 234956
2015-04-14 23:45:11 +00:00
Duncan P. N. Exon Smith 7ad0bd54d3 DebugInfo: Make MDSubprogram::getFunction() return Constant
Change `MDSubprogram::getFunction()` and
`MDGlobalVariable::getConstant()` to return a `Constant`.  Previously,
both returned `ConstantAsMetadata`.

llvm-svn: 234699
2015-04-11 20:27:40 +00:00
Duncan P. N. Exon Smith 1134473f51 IR: Remove MDTupleTypedArrayWrapper::operator MDTuple*()
Remove `MDTupleTypedArrayWrapper::operator MDTuple*()`, since it causes
ambiguity (at least in some [1] compilers [2]) when using indexes to
`MDTupleTypedArrayWrapper::operator[](unsigned)` that are convertible to
(but not the same as) `unsigned`.

[1]: http://lab.llvm.org:8011/builders/sanitizer-windows/builds/2308
[2]: http://lab.llvm.org:8011/builders/clang-cmake-mips/builds/4442

llvm-svn: 234326
2015-04-07 16:50:39 +00:00
Duncan P. N. Exon Smith 5dcf621c8a IR: Rename MDSubrange::getLo() to getLowerBound()
During initial review, the `lo:` field was renamed to `lowerBound:`.
Make the same change to the C++ API.

llvm-svn: 234267
2015-04-07 00:39:59 +00:00
Duncan P. N. Exon Smith ab659fb3d0 IR: Use the new DebugLoc API, NFC
Update lib/IR and lib/Bitcode to use the new `DebugLoc` API.  Added an
explicit conversion to `bool` (avoiding a conversion to `MDLocation`),
since a couple of these use cases need to handle broken code.

llvm-svn: 233585
2015-03-30 19:40:05 +00:00
Duncan P. N. Exon Smith 1facf7a13d Bitcode: Reflow code to use early continues, NFC
llvm-svn: 233578
2015-03-30 18:29:18 +00:00
Duncan P. N. Exon Smith 79f8d11d5a AsmWriter: Assert on unresolved metadata nodes
Assert that `MDNode::isResolved()`.  While in theory the `Verifier`
should catch this, it doesn't descend into all debug info, and the
`DebugInfoVerifier` doesn't call into the `Verifier`.  Besides, this
helps to catch bugs when `-disable-verify=true`.

Note that I haven't come across a place where this fails with clang
today, so no testcase.

llvm-svn: 232442
2015-03-17 00:16:35 +00:00
David Blaikie b9263570a5 [opaque pointer type] Bitcode support for explicit type parameter on the gep operator
This happened to be fairly easy to support backwards compatibility based
on the number of operands (old format had an even number, new format has
one more operand so an odd number).

test/Bitcode/old-aliases.ll already appears to test old gep operators
(if I remove the backwards compatibility in the BitcodeReader, this and
another test fail) so I'm not adding extra test coverage here.

llvm-svn: 232216
2015-03-13 21:03:36 +00:00
David Blaikie b5b5efd2d1 [opaque pointer type] Bitcode support for explicit type parameter on GEP.
Like r230414, add bitcode support including backwards compatibility, for
an explicit type parameter to GEP.

At the suggestion of Duncan I tried coalescing the two older bitcodes into a
single new bitcode, though I did hit a wrinkle: I couldn't figure out how to
create an explicit abbreviation for a record with a variable number of
arguments (the indicies to the gep). This means the discriminator between
inbounds and non-inbounds gep is a full variable-length field I believe? Is my
understanding correct? Is there a way to create such an abbreviation? Should I
just use two bitcodes as before?

Reviewers: dexonsmith

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

llvm-svn: 230415
2015-02-25 01:08:52 +00:00
David Blaikie 8503565eec [opaque pointer type] bitcode support for explicit type parameter to the load instruction
Summary:
I've taken my best guess at this, but I've cargo culted in places & so
explanations/corrections would be great.

This seems to pass all the tests (check-all, covering clang and llvm) so I
believe that pretty well exercises both the backwards compatibility and common
(same version) compatibility given the number of checked in bitcode files we
already have. Is that a reasonable approach to testing here? Would some more
explicit tests be desired?

1) is this the right way to do back-compat in this case (looking at the number
  of entries in the bitcode record to disambiguate between the old schema and
  the new?)

2) I don't quite understand the logarithm logic to choose the encoding type of
  the type parameter in the abbreviation description, but I found another
  instruction doing the same thing & it seems to work. Is that the right
  approach?

Reviewers: dexonsmith

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

llvm-svn: 230414
2015-02-25 01:07:20 +00:00
David Blaikie 7b0281089e BitcodeWriter: Refactor common computation of bits required for a type index.
Suggested by Duncan. Happy to bikeshed the name, cache the result, etc.

llvm-svn: 230410
2015-02-25 00:51:52 +00:00
Duncan P. N. Exon Smith ad6eb127c9 Bitcode: Stop assuming non-null fields
When writing the bitcode serialization for the new debug info hierarchy,
I assumed two fields would never be null.

Drop that assumption, since it's brittle (and crashes the
`BitcodeWriter` if wrong), and is a check better left for the verifier
anyway.  (No need for a bitcode upgrade here, since the new hierarchy is
still not in place.)

The fields in question are `MDCompileUnit::getFile()` and
`MDDerivedType::getBaseType()`, the latter of which isn't null in
test/Transforms/Mem2Reg/ConvertDebugInfo2.ll (see !14, a pointer to
nothing).  While the testcase might have bitrotted, there's no reason
for the bitcode format to rely on non-null for metadata operands.

This also fixes a bug in `AsmWriter` where if the `file:` is null it
isn't emitted (caught by the double-round trip in the testcase I'm
adding) -- this is a required field in `LLParser`.

I'll circle back to ConvertDebugInfo2.  Once the specialized nodes are
in place, I'll be trying to turn the debug info verifier back on by
default (in the newer module pass form committed r206300) and throwing
more logic in there.  If the testcase has bitrotted (as opposed to me
not understanding the schema correctly) I'll fix it then.

llvm-svn: 229960
2015-02-20 03:17:58 +00:00
Duncan P. N. Exon Smith 3d62bbacb1 IR: Drop scope from MDTemplateParameter
Follow-up to r229740, which removed `DITemplate*::getContext()` after my
upgrade script revealed that scopes are always `nullptr` for template
parameters.  This is the other shoe: drop `scope:` from
`MDTemplateParameter` and its two subclasses.  (Note: a bitcode upgrade
would be pointless, since the hierarchy hasn't been moved into place.)

llvm-svn: 229791
2015-02-19 00:37:21 +00:00
Benjamin Kramer 6cd780ff21 Prefer SmallVector::append/insert over push_back loops.
Same functionality, but hoists the vector growth out of the loop.

llvm-svn: 229500
2015-02-17 15:29:18 +00:00
Duncan P. N. Exon Smith 1c93116489 AsmWriter/Bitcode: MDImportedEntity
llvm-svn: 229025
2015-02-13 01:46:02 +00:00
Duncan P. N. Exon Smith d45ce96c38 AsmWriter/Bitcode: MDObjCProperty
llvm-svn: 229024
2015-02-13 01:43:22 +00:00
Duncan P. N. Exon Smith 0c5c0124ac AsmWriter/Bitcode: MDExpression
llvm-svn: 229023
2015-02-13 01:42:09 +00:00
Duncan P. N. Exon Smith 72fe2d0b79 AsmWriter/Bitcode: MDLocalVariable
llvm-svn: 229022
2015-02-13 01:39:44 +00:00
Duncan P. N. Exon Smith c8f810a017 AsmWriter/Bitcode: MDGlobalVariable
llvm-svn: 229020
2015-02-13 01:35:40 +00:00
Duncan P. N. Exon Smith 2847f3805e AsmWriter/Bitcode: MDTemplate{Type,Value}Parameter
llvm-svn: 229019
2015-02-13 01:34:32 +00:00
Duncan P. N. Exon Smith e146000565 AsmWriter/Bitcode: MDNamespace
llvm-svn: 229018
2015-02-13 01:32:09 +00:00
Duncan P. N. Exon Smith 06a0702e40 AsmWriter/Bitcode: MDLexicalBlockFile
llvm-svn: 229017
2015-02-13 01:30:42 +00:00
Duncan P. N. Exon Smith a96d409997 AsmWriter/Bitcode: MDLexicalBlock
llvm-svn: 229016
2015-02-13 01:29:28 +00:00
Duncan P. N. Exon Smith 19fc5ed7db AsmWriter/Bitcode: MDSubprogram
llvm-svn: 229014
2015-02-13 01:26:47 +00:00
Duncan P. N. Exon Smith c1f1acc751 AsmWriter/Bitcode: MDCompileUnit
llvm-svn: 229013
2015-02-13 01:25:10 +00:00
Duncan P. N. Exon Smith 54e2bc6c9b AsmWriter/Bitcode: MDSubroutineType
llvm-svn: 229011
2015-02-13 01:22:59 +00:00
Duncan P. N. Exon Smith 171d077ae4 AsmWriter/Bitcode: MDDerivedType and MDCompositeType
llvm-svn: 229009
2015-02-13 01:20:38 +00:00
Duncan P. N. Exon Smith f14b9c7cc1 AsmWriter/Bitcode: MDFile
llvm-svn: 229007
2015-02-13 01:19:14 +00:00
Duncan P. N. Exon Smith 09e03f38d6 AsmWriter/Bitcode: MDBasicType
llvm-svn: 229005
2015-02-13 01:14:58 +00:00
Duncan P. N. Exon Smith 8775476419 AsmWriter/Bitcode: MDEnumerator
llvm-svn: 229004
2015-02-13 01:14:11 +00:00
Duncan P. N. Exon Smith c7363f1147 AsmWriter/Bitcode: MDSubrange
llvm-svn: 229003
2015-02-13 01:10:38 +00:00
Duncan P. N. Exon Smith 01fc176977 IR: Add specialized debug info metadata nodes
Add specialized debug info metadata nodes that match the `DIDescriptor`
wrappers (used by `DIBuilder`) closely.  Assembly and bitcode support to
follow soon (it'll mostly just be obvious), but this sketches in today's
schema.  This is the first big commit (well, the only *big* one aside
from the testcase changes that'll come when I move this into place) for
PR22464.

I've marked a bunch of obvious changes as `TODO`s in the source; I plan
to make those changes promptly after this hierarchy is moved underneath
`DIDescriptor`, but for now I'm aiming mostly to match the status quo.

llvm-svn: 228640
2015-02-10 00:52:32 +00:00
Duncan P. N. Exon Smith 6b7b680efd IR: Initialize MDNode abbreviations en masse, NFC
llvm-svn: 228203
2015-02-04 21:54:12 +00:00
Peter Collingbourne 69ba0167b3 Misc documentation/comment fixes.
llvm-svn: 228093
2015-02-04 00:42:45 +00:00
Duncan P. N. Exon Smith 4e4aa70535 IR: Assembly and bitcode for GenericDebugNode
llvm-svn: 228041
2015-02-03 21:54:14 +00:00
Duncan P. N. Exon Smith d9901ff586 IR: Split out DebugInfoMetadata.h, NFC
Move debug-info-centred `Metadata` subclasses into their own
header/source file.  A couple of private template functions are needed
from both `Metadata.cpp` and `DebugInfoMetadata.cpp`, so I've moved them
to `lib/IR/MetadataImpl.h`.

llvm-svn: 227835
2015-02-02 18:53:21 +00:00
Duncan P. N. Exon Smith e8b5e49ffd IR: DwarfNode => DebugNode, NFC
These things are potentially used for non-DWARF data (see the discussion
in PR22235), so take the `Dwarf` out of the name.  Since the new name
gives fewer clues, update the doxygen to properly describe what they
are.

llvm-svn: 226874
2015-01-22 22:47:44 +00:00
Duncan P. N. Exon Smith db6bc8bfdf Bitcode: Simplify MDNode subclass dispatch, NFC
llvm-svn: 226535
2015-01-20 01:03:09 +00:00
Duncan P. N. Exon Smith 6592deeab2 Bitcode: WriteMDNode() => WriteMDTuple(), NFC
llvm-svn: 226534
2015-01-20 01:01:53 +00:00
Duncan P. N. Exon Smith 9a6f64e7b8 Bitcode: Add ValueEnumerator::getMetadataOrNullID(), NFC
llvm-svn: 226533
2015-01-20 01:00:23 +00:00
Rafael Espindola 12ca34f53f Bring r226038 back.
No change in this commit, but clang was changed to also produce trivial comdats when
needed.

Original message:

Don't create new comdats in CodeGen.

This patch stops the implicit creation of comdats during codegen.

Clang now sets the comdat explicitly when it is required. With this patch clang and gcc
now produce the same result in pr19848.

llvm-svn: 226467
2015-01-19 15:16:06 +00:00
Timur Iskhodzhanov 60b721363c Revert r226242 - Revert Revert Don't create new comdats in CodeGen
This breaks AddressSanitizer (ninja check-asan) on Windows

llvm-svn: 226251
2015-01-16 08:38:45 +00:00
Rafael Espindola 67a79e72f5 Revert "Revert Don't create new comdats in CodeGen"
This reverts commit r226173, adding r226038 back.

No change in this commit, but clang was changed to also produce trivial comdats for
costructors, destructors and vtables when needed.

Original message:

Don't create new comdats in CodeGen.

This patch stops the implicit creation of comdats during codegen.

Clang now sets the comdat explicitly when it is required. With this patch clang and gcc
now produce the same result in pr19848.

llvm-svn: 226242
2015-01-16 02:22:55 +00:00
Timur Iskhodzhanov f5adf13fac Revert Don't create new comdats in CodeGen
It breaks AddressSanitizer on Windows.

llvm-svn: 226173
2015-01-15 16:14:34 +00:00
Rafael Espindola fad1639a12 Don't create new comdats in CodeGen.
This patch stops the implicit creation of comdats during codegen.

Clang now sets the comdat explicitly when it is required. With this patch clang and gcc
now produce the same result in pr19848.

llvm-svn: 226038
2015-01-14 20:55:48 +00:00
Rafael Espindola 4e74d3be35 Add support for comdats with names larger than 256 characters.
llvm-svn: 226012
2015-01-14 18:25:45 +00:00
Duncan P. N. Exon Smith 6a4848324b AsmParser/Bitcode: Add support for MDLocation
This adds assembly and bitcode support for `MDLocation`.  The assembly
side is rather big, since this is the first `MDNode` subclass (that
isn't `MDTuple`).  Part of PR21433.

(If you're wondering where the mountains of testcase updates are, we
don't need them until I update `DILocation` and `DebugLoc` to actually
use this class.)

llvm-svn: 225830
2015-01-13 21:10:44 +00:00
Duncan P. N. Exon Smith 49503f827d Bitcode: Range-based for, NFC
llvm-svn: 225716
2015-01-12 22:35:34 +00:00