Commit Graph

946 Commits

Author SHA1 Message Date
David Blaikie
93a23a3bd4 Recommit r235458: [opaque pointer type] Avoid using PointerType::getElementType for a few cases of CallInst
(reverted in r235533)

Original commit message:

"Calls to llvm::Value::mutateType are becoming extra-sensitive now that
instructions have extra type information that will not be derived from
operands or result type (alloca, gep, load, call/invoke, etc... ). The
special-handling for mutateType will get more complicated as this work
continues - it might be worth making mutateType virtual & pushing the
complexity down into the classes that need special handling. But with
only two significant uses of mutateType (vectorization and linking) this
seems OK for now.

Totally open to ideas/suggestions/improvements, of course.

With this, and a bunch of exceptions, we can roundtrip an indirect call
site through bitcode and IR. (a direct call site is actually trickier...
I haven't figured out how to deal with the IR deserializer's lazy
construction of Function/GlobalVariable decl's based on the type of the
entity which means looking through the "pointer to T" type referring to
the global)"

The remapping done in ValueMapper for LTO was insufficient as the types
weren't correctly mapped (though I was using the post-mapped operands,
some of those operands might not have been mapped yet so the type
wouldn't be post-mapped yet). Instead use the pre-mapped type and
explicitly map all the types.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235651 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-23 21:36:23 +00:00
Filipe Cabecinhas
0236022390 Be more strict about the operand for the array type in BitcodeReader
Summary: Bug found with AFL fuzz.

Reviewers: rafael

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235596 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-23 13:38:21 +00:00
Filipe Cabecinhas
81f9bd3e19 Verify sizes when trying to read a BitcodeAbbrevOp
Summary:
Make sure the abbrev operands are valid and that we can read/skip them
afterwards.

Bug found with AFL fuzz.

Reviewers: rafael

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235595 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-23 13:25:35 +00:00
David Blaikie
cfe6126e17 Revert "[opaque pointer type] Avoid using PointerType::getElementType for a few cases of CallInst"
This reverts commit r235458.

It looks like this might be breaking something LTO-ish. Looking into it
& will recommit with a fix/test case/etc once I've got more to go on.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235533 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-22 18:16:49 +00:00
Filipe Cabecinhas
e16cac587a Have more strict type checks when creating BinOp nodes in BitcodeReader
Summary: Bug found with AFL.

Reviewers: rafael, bkramer

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235489 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-22 09:06:21 +00:00
David Blaikie
5bd65c73d7 [opaque pointer types] Serialize the value type for atomic 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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235475 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-22 04:14:46 +00:00
David Blaikie
5db5cae26f [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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235474 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-22 04:14:42 +00:00
David Blaikie
d62a1e966c [opaque pointer type] Avoid using PointerType::getElementType for a few cases of CallInst
Calls to llvm::Value::mutateType are becoming extra-sensitive now that
instructions have extra type information that will not be derived from
operands or result type (alloca, gep, load, call/invoke, etc... ). The
special-handling for mutateType will get more complicated as this work
continues - it might be worth making mutateType virtual & pushing the
complexity down into the classes that need special handling. But with
only two significant uses of mutateType (vectorization and linking) this
seems OK for now.

Totally open to ideas/suggestions/improvements, of course.

With this, and a bunch of exceptions, we can roundtrip an indirect call
site through bitcode and IR. (a direct call site is actually trickier...
I haven't figured out how to deal with the IR deserializer's lazy
construction of Function/GlobalVariable decl's based on the type of the
entity which means looking through the "pointer to T" type referring to
the global)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235458 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-21 23:26:57 +00:00
David Blaikie
0f0d21e869 [opaque pointer types] Use the pointee type loaded from bitcode when constructing a LoadInst
Now (with a few carefully placed suppressions relating to general type
serialization, etc) we can round trip a simple load through bitcode and
textual IR without calling getElementType on a PointerType.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235221 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-17 19:56:21 +00:00
David Blaikie
6aa30ccfdb [opaque pointer type] Serialize the type of an llvm::Function as a function type rather than a function pointer type
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235200 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-17 16:28:26 +00:00
David Blaikie
5023f151a7 [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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235160 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-17 06:40:14 +00:00
Sanjoy Das
5ff5907996 [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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235132 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-16 20:29:50 +00:00
Duncan P. N. Exon Smith
88e419d66e 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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235050 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-15 22:29:27 +00:00
Filipe Cabecinhas
f72ee4c275 Revert "Verify sizes when trying to read a VBR"
This reverts r234984 since it seems to break some bots (most of them
seemed arm*-selfhost).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234998 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-15 11:10:17 +00:00
Filipe Cabecinhas
4c0055402f Verify sizes when trying to read a VBR
Also added an assert to ReadVBR64.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234984 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-15 08:48:08 +00:00
Duncan P. N. Exon Smith
8d61ee9e7d uselistorder: Remove the global bits
Remove all the global bits to do with preserving use-list order by
moving the `cl::opt`s to the individual tools that want them.  There's a
minor functionality change to `libLTO`, in that you can't send in
`-preserve-bc-uselistorder=false`, but making that bit settable (if it's
worth doing) should be through explicit LTO API.

As a drive-by fix, I removed some includes of `UseListOrder.h` that were
made unnecessary by recent commits.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234973 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-15 03:14:06 +00:00
Duncan P. N. Exon Smith
e005d71e4b uselistorder: Pull bit through BitcodeWriterPass
Now the callers of `BitcodeWriterPass` decide whether or not to preserve
bitcode use-list order.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234959 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-15 00:34:24 +00:00
Duncan P. N. Exon Smith
657aad675a 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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234957 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-15 00:10:50 +00:00
Duncan P. N. Exon Smith
d01ee74ffa 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()`.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234956 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-14 23:45:11 +00:00
Filipe Cabecinhas
9a1030a4d6 Error out of ParseBitcodeInto(Module*) if we haven't read a Module
Summary:
Without this check the following case failed:

Skip a SubBlock which is not a MODULE_BLOCK_ID nor a BLOCKINFO_BLOCK_ID
Got to end of file

TheModule would still be == nullptr, and we would subsequentially fail
when materializing the Module (assert at the start of
BitcodeReader::MaterializeModule).

Bug found with AFL.

Reviewers: dexonsmith, rafael

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234887 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-14 14:07:15 +00:00
Duncan P. N. Exon Smith
e2e641234f DebugInfo: Make MDSubprogram::getFunction() return Constant
Change `MDSubprogram::getFunction()` and
`MDGlobalVariable::getConstant()` to return a `Constant`.  Previously,
both returned `ConstantAsMetadata`.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234699 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-11 20:27:40 +00:00
Alexander Kornienko
c16fc54851 Use 'override/final' instead of 'virtual' for overridden methods
The patch is generated using clang-tidy misc-use-override check.

This command was used:

  tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \
    -checks='-*,misc-use-override' -header-filter='llvm|clang' \
    -j=32 -fix -format

http://reviews.llvm.org/D8925



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234679 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-11 02:11:45 +00:00
Duncan P. N. Exon Smith
2e25115e02 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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234326 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-07 16:50:39 +00:00
Duncan P. N. Exon Smith
329f8219cd IR: Rename MDSubrange::getLo() to getLowerBound()
During initial review, the `lo:` field was renamed to `lowerBound:`.
Make the same change to the C++ API.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234267 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-07 00:39:59 +00:00
David Blaikie
19443c1bcb [opaque pointer type] API migration for GEP constant factories
Require the pointee type to be passed explicitly and assert that it is
correct. For now it's possible to pass nullptr here (and I've done so in
a few places in this patch) but eventually that will be disallowed once
all clients have been updated or removed. It'll be a long road to get
all the way there... but if you have the cahnce to update your callers
to pass the type explicitly without depending on a pointer's element
type, that would be a good thing to do soon and a necessary thing to do
eventually.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233938 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-02 18:55:32 +00:00
Rafael Espindola
4eeb5e9c69 git-clang-format r233603.
Thanks to Meador Inge for noticing.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233808 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-01 14:44:59 +00:00
Rafael Espindola
a55ae077e4 Fix PR23045.
Keep a note in the materializer that we are stripping debug info so that
user doing a lazy read of the module don't hit outdated formats.

Thanks to Duncan for suggesting the fix.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233603 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 21:36:43 +00:00
Duncan P. N. Exon Smith
39acf8f243 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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233585 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 19:40:05 +00:00
Duncan P. N. Exon Smith
d0db611445 Bitcode: Reflow code to use early continues, NFC
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233578 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 18:29:18 +00:00
Duncan P. N. Exon Smith
c4eafd24f2 Verifier: Check accessors of MDLocation
Check accessors of `MDLocation`, and change them to `cast<>` down to the
right types.  Also add type-safe factory functions.

All the callers that handle broken code need to use the new versions of
the accessors (`getRawScope()` instead of `getScope()`) that still
return `Metadata*`.  This is also necessary for things like
`MDNodeKeyImpl<MDLocation>` (in LLVMContextImpl.h) that need to unique
the nodes when their operands might still be forward references of the
wrong type.

In the `Value` hierarchy, consumers that handle broken code use
`getOperand()` directly.  However, debug info nodes have a ton of
operands, and their order (even their existence) isn't stable yet.  It's
safer and more maintainable to add an explicit "raw" accessor on the
class itself.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233322 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-26 22:05:04 +00:00
Benjamin Kramer
e3154fb22d Internalize BitcodeReader. Not used outside of BitcodeReader.cpp.
NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232542 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-17 20:40:24 +00:00
Duncan P. N. Exon Smith
b47d918825 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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232442 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-17 00:16:35 +00:00
David Blaikie
712d00bc64 Add testing for mismatched explicit type on a gep operator when loading from bitcode
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232427 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-16 22:03:50 +00:00
David Blaikie
2a83bf6228 Add testing for mismatched explicit type on a load instruction when loading from bitcode
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232424 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-16 21:48:46 +00:00
David Blaikie
f1d4614418 Test bitcode parsing error-handling for incorrect explicit type
(turns out I had regressed this when sinking handling of this type down
into GetElementPtrInst::Create - since that asserted before the error
handling was performed)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232420 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-16 21:35:48 +00:00
David Blaikie
f508adde2e [opaque pointer type] more gep API migration
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232274 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-14 19:53:33 +00:00
Rafael Espindola
dc6141a4ff Be lazy about loading metadata in IRObjectFile.
This speeds up llvm-ar building lib64/libclangSema.a with debug IR files
from 8.658015807 seconds to just 0.351036519 seconds :-)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232221 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-13 21:54:20 +00:00
David Blaikie
1f48a55e86 [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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232216 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-13 21:03:36 +00:00
David Blaikie
75cc2505da Turn assertion into bitcode reading error
I don't think we test invalid bitcode records in any detail, so no test
here - just a change for consistency with existing error checks in
surrounding code.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232215 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-13 21:03:34 +00:00
Manman Ren
cd67bbf07f Add a parameter for getLazyBitcodeModule to lazily load Metadata.
We only defer loading metadata inside ParseModule when ShouldLazyLoadMetadata
is true and we have not loaded any Metadata block yet.

This commit implements all-or-nothing loading of Metadata. If there is a
request to load any metadata block, we will load all deferred metadata blocks.

We make sure the deferred metadata blocks are loaded before we materialize any
function or a module.

The default value of the added parameter ShouldLazyLoadMetadata for
getLazyBitcodeModule is false, so the default behavior stays the same.

We only set the parameter to true when creating LTOModule in local contexts.
These can only really be used for parsing symbols, so it's unnecessary to ever
load the metadata blocks.

If we are going to enable lazy-loading of Metadata for other usages of
getLazyBitcodeModule, where deferred metadata blocks need to be loaded, we can
expose BitcodeReader::materializeMetadata to Module, similar to
Module::materialize.

rdar://19804575


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232198 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-13 19:24:30 +00:00
David Blaikie
da4471d726 Simplify expressions involving boolean constants with clang-tidy
Patch by Richard (legalize at xmission dot com).

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231617 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-09 01:57:13 +00:00
Benjamin Kramer
d59c5f9a06 Add missing includes. make_unique proliferated everywhere.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230909 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-01 21:28:53 +00:00
Yaron Keren
3ab51efa6d Silence three more variable set but not used warnings, NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230853 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-28 15:29:17 +00:00
David Blaikie
6606ad944b [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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230415 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-25 01:08:52 +00:00
David Blaikie
5e2e6f2855 [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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230414 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-25 01:07:20 +00:00
David Blaikie
6bc72f8262 BitcodeWriter: Refactor common computation of bits required for a type index.
Suggested by Duncan. Happy to bikeshed the name, cache the result, etc.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230410 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-25 00:51:52 +00:00
JF Bastien
8c253f7e88 Use common parse routine to read alignment values from bitcode
While fuzzing LLVM bitcode files, I discovered that (1) the bitcode reader doesn't check that alignments are no larger than 2**29; (2) downstream code doesn't check the range; and (3) for values out of range, corresponding large memory requests (based on alignment size) will fail. This code fixes the bitcode reader to check for valid alignments, fixing this problem.

This CL fixes alignment value on global variables, functions, and instructions: alloca, load, load atomic, store, store atomic.

Patch by Karl Schimpf (kschimpf@google.com).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230180 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-22 19:32:03 +00:00
Duncan P. N. Exon Smith
ea8cbe9782 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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229960 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-20 03:17:58 +00:00
Duncan P. N. Exon Smith
eac950e408 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.)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229791 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-19 00:37:21 +00:00
Benjamin Kramer
1a50a12b43 Prefer SmallVector::append/insert over push_back loops.
Same functionality, but hoists the vector growth out of the loop.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229500 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-17 15:29:18 +00:00