summaryrefslogtreecommitdiffstats
path: root/llvm/test/Bitcode
Commit message (Collapse)AuthorAgeFilesLines
...
* DI: Require subprogram definitions to be distinctDuncan P. N. Exon Smith2015-08-284-3/+14
| | | | | | | | | | | | | | | | | | | | | | | | As a follow-up to r246098, require `DISubprogram` definitions (`isDefinition: true`) to be 'distinct'. Specifically, add an assembler check, a verifier check, and bitcode upgrading logic to combat testcase bitrot after the `DIBuilder` change. While working on the testcases, I realized that test/Linker/subprogram-linkonce-weak-odr.ll isn't relevant anymore. Its purpose was to check for a corner case in PR22792 where two subprogram definitions match exactly and share the same metadata node. The new verifier check, requiring that subprogram definitions are 'distinct', precludes that possibility. I updated almost all the IR with the following script: git grep -l -E -e '= !DISubprogram\(.* isDefinition: true' | grep -v test/Bitcode | xargs sed -i '' -e 's/= \(!DISubprogram(.*, isDefinition: true\)/= distinct \1/' Likely some variant of would work for out-of-tree testcases. llvm-svn: 246327
* [test] Testing write access to llvmVedant Kumar2015-08-141-1/+1
| | | | llvm-svn: 245074
* [IR] Add token typesDavid Majnemer2015-08-141-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Emit argmemonly attribute for intrinsics.Igor Laevsky2015-08-132-5/+11
| | | | | | Differential Revision: http://reviews.llvm.org/D11352 llvm-svn: 244920
* [compatibility.ll] Cover explicitly named comdats.Sean Silva2015-08-062-0/+8
| | | | | | Patch by Vedant Kumar! <vsk@apple.com> llvm-svn: 244284
* Fix testing for end of stream in bitstream reader.Derek Schuff2015-08-031-0/+0
| | | | | | | | | | | | | | | | | | This fixes a bug found while working on the bitcode reader. In particular, the method BitstreamReader::AtEndOfStream doesn't always behave correctly when processing a data streamer. The method fillCurWord doesn't properly set CurWord/BitsInCurWord if the data streamer was already at eof, but GetBytes had not yet set the ObjectSize field of the streaming memory object. This patch fixes this problem, and provides a test to show that this problem has been fixed. Patch by Karl Schimpf. Differential Revision: http://reviews.llvm.org/D11391 llvm-svn: 243890
* DI: Disallow uniquable DICompileUnitsDuncan P. N. Exon Smith2015-08-032-3/+3
| | | | | | | | | | | | | | | | | | 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
* Currently string attributes on function arguments/return values can be ↵Artur Pilipenko2015-08-031-0/+10
| | | | | | | | | | | | | | | generated using LLVM API. However they are not supported in parser. So, the following scenario will fail: * generate function with string attribute using API, * dump it in LL format, * try to parse. Add parser support for string attributes to fix the issue. Reviewed By: reames, hfinkel Differential Revision: http://reviews.llvm.org/D11058 llvm-svn: 243877
* IR: Add a broad bitcode compatibility testDuncan P. N. Exon Smith2015-07-313-0/+2475
| | | | | | | | | | | | | | | | Successive versions of LLVM should retain the ability to parse bitcode generated by old releases of the compiler. This adds a bitcode format compatibility test, which is intended to provide good (albeit not entirely exhaustive) coverage of the current LangRef. This also includes compatibility tests for LLVM 3.6. After every 3.X.0 release, the compatibility.ll file from the 3.X branch should be copied to compatibility-3.X.ll on trunk, and the 3.X.0 release used to generate a corresponding bitcode file. Patch by Vedant Kumar! llvm-svn: 243779
* DI: Remove DW_TAG_arg_variable and DW_TAG_auto_variableDuncan P. N. Exon Smith2015-07-312-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Add argmemonly attribute.Igor Laevsky2015-07-111-2/+9
| | | | | | | | 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
* Add support for fast-math flags to the FCmp instruction.James Molloy2015-07-101-0/+23
| | | | | | | | | | | | | | 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
* Fix for PR23310: llvm-dis crashes when trying to upgrade an intrinsic.Rafael Espindola2015-07-022-0/+1
| | | | | | | | | | | | When trying to upgrade @llvm.x86.sse2.psrl.dq while parsing a module, BitcodeReader adds the function to its worklist twice, resulting in a crash when accessing it the second time. This patch replaces the worklist vector by a map. Patch by Philip Pfaffe. llvm-svn: 241281
* Move the personality function from LandingPadInst to FunctionDavid Majnemer2015-06-171-3/+9
| | | | | | | | | | | | | | | | | | | 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
* Improve handling of end of file in the bitcode reader.Rafael Espindola2015-06-162-2/+7
| | | | | | | | | | | | | | | | | | | | | | Before this patch the bitcode reader would read a module from a file that contained in order: * Any number of non MODULE_BLOCK sub blocks. * One MODULE_BLOCK * Any number of non MODULE_BLOCK sub blocks. * 4 '\n' characters to handle OS X's ranlib. Since we support lazy reading of modules, any information that is relevant for the module has to be in the MODULE_BLOCK or before it. We don't gain anything from checking what is after. This patch then changes the reader to stop once the MODULE_BLOCK has been successfully parsed. This avoids the ugly special case for .bc files in an archive and makes it easier to embed bitcode files. llvm-svn: 239845
* Add a test for padded bitcode files.Rafael Espindola2015-06-162-0/+13
| | | | llvm-svn: 239829
* [BitcodeReader] Diagnose type mismatches with aliasesFilipe Cabecinhas2015-06-032-0/+5
| | | | | | Bug found with AFL fuzz. llvm-svn: 238895
* [Bitcode] Minimize the test to not conflict with othersFilipe Cabecinhas2015-06-031-0/+0
| | | | | | | | | Source for the test: @bloom = global <3 x i32> <i32 0, i32 1, i32 42> Plus bit twiddling to set the vector numelts to 0 (in the bc file). llvm-svn: 238894
* [BitcodeReader] Check vector size before trying to create a VectorTypeFilipe Cabecinhas2015-06-032-0/+5
| | | | | | Bug found with AFL fuzz llvm-svn: 238891
* [BitcodeReader] Change an assert to a call to a call to Error()Filipe Cabecinhas2015-05-302-0/+5
| | | | | | | | It's reachable from user input. Bug found with AFL fuzz. llvm-svn: 238633
* [BitcodeReader] Change assert to report_fatal_errorFilipe Cabecinhas2015-05-272-0/+5
| | | | | | | | It can be triggered by user input. Bug found with AFL fuzz. llvm-svn: 238272
* [BitstreamReader] Make sure the Array operand type is an encodingFilipe Cabecinhas2015-05-272-0/+5
| | | | | | Bug found with AFL fuzz. llvm-svn: 238269
* [BitcodeReader] Make sure abbrev records have at least one operand (record code)Filipe Cabecinhas2015-05-262-0/+5
| | | | | | Bug found with AFL fuzz. llvm-svn: 238265
* Add initial support for the convergent attribute.Owen Anderson2015-05-261-2/+8
| | | | llvm-svn: 238264
* [BitcodeReader] Sanity check on Comdat IDFilipe Cabecinhas2015-05-263-0/+10
| | | | | | | | Shouldn't be an assert, since user input can trigger it. Bug found with AFL fuzz. llvm-svn: 238261
* IR / debug info: Add a DWOId field to DICompileUnit,Adrian Prantl2015-05-212-0/+9
| | | | | | | | | | | | | | | | | | | | | | 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
* Change a reachable unreachable to a fatal error.Filipe Cabecinhas2015-05-192-0/+5
| | | | | | | | | | | | | | | Summary: Also tagged a FIXME comment, and added information about why it breaks. Bug found using AFL fuzz. Reviewers: rafael, craig.topper Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9729 llvm-svn: 237709
* [BitcodeReader] Error out if we read an invalid function argument typeFilipe Cabecinhas2015-05-192-0/+5
| | | | | | Bug found with AFL fuzz. llvm-svn: 237650
* [BitcodeReader] It's a malformed block if CodeLenWidth is too bigFilipe Cabecinhas2015-05-192-0/+5
| | | | | | Bug found with AFL fuzz. llvm-svn: 237646
* [BitcodeReader] Make sure the type of the inserted value matches the type of ↵Filipe Cabecinhas2015-05-182-0/+5
| | | | | | | | the aggregate at those indices Bug found with AFL-fuzz. llvm-svn: 237628
* Extract the load/store type verification to a separate function.Filipe Cabecinhas2015-05-182-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Added isLoadableOrStorableType to PointerType. We were doing some checks in some places, occasionally assert()ing instead of telling the caller. With this patch, I'm putting all type checking in the same place for load/store type instructions, and verifying the same thing every time. I also added a check for load/store of a function type. Applied extracted check to Load, Store, and Cmpxcg. I don't have exhaustive tests for all of these, but all Error() calls in TypeCheckLoadStoreInst are being tested (in invalid.test). Reviewers: dblaikie, rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9785 llvm-svn: 237619
* [BitcodeReader] Don't allow INSERTVAL/EXTRACTVAL with 0 indicesFilipe Cabecinhas2015-05-163-0/+10
| | | | | | | | This would trigger an assertion later. Bug found with AFL fuzz. llvm-svn: 237494
* Bitcode: Set LastDL after writing DebugLocsDuncan P. N. Exon Smith2015-05-061-0/+36
| | | | | | | | | | 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
* Don't overflow GCTableFilipe Cabecinhas2015-04-302-0/+5
| | | | | | | | | | | | Summary: Bug found with AFL fuzz. Reviewers: rafael, dexonsmith Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9361 llvm-svn: 236200
* Make sure Op->getType() is a PointerType before we cast<> it.Filipe Cabecinhas2015-04-302-0/+5
| | | | | | Bug found with AFL fuzz. llvm-svn: 236193
* Make sure we don't resize(0) when we get a fwdref with Idx == UINT_MAXFilipe Cabecinhas2015-04-302-0/+5
| | | | | | | | Make it an error instead. Bug found with AFL fuzz. llvm-svn: 236190
* Check that we have a valid PointerType element type before calling get()Filipe Cabecinhas2015-04-292-0/+2
| | | | | | | | Same as r236073 but for PointerType. Bug found with AFL fuzz. llvm-svn: 236079
* Turn an assert into report_fatal_error since it's reachable based on user inputFilipe Cabecinhas2015-04-292-0/+5
| | | | | | Bug found with AFL fuzz. llvm-svn: 236076
* Make sure that isValidElementType(Type) before calling ↵Filipe Cabecinhas2015-04-293-0/+7
| | | | | | | | {Array,Struct}Type::get(Type) Bug found with AFL fuzz. llvm-svn: 236073
* Relax an assert when there's a type mismatch in forward referencesFilipe Cabecinhas2015-04-282-0/+5
| | | | | | | | | | | | | | | | Summary: We don't seem to need to assert here, since this function's callers expect to get a nullptr on error. This way we don't assert on user input. Bug found with AFL fuzz. Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9308 llvm-svn: 236027
* [opaque pointer type] Encode the pointee type in the bitcode for 'cmpxchg'David Blaikie2015-04-282-0/+13
| | | | | | | | | | | | | | | | | 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
* [opaque pointer type] bitcode: add explicit callee type to invoke instructionsDavid Blaikie2015-04-243-0/+6
| | | | llvm-svn: 235735
* [BitcodeReader] Fix asserts when we read a non-vector type for ↵Filipe Cabecinhas2015-04-244-0/+9
| | | | | | | | | | insert/extract/shuffle Added some additional checking for vector types + tests. Bug found with AFL fuzz. llvm-svn: 235710
* Be more strict about the operand for the array type in BitcodeReaderFilipe Cabecinhas2015-04-232-0/+5
| | | | | | | | | | | | Summary: Bug found with AFL fuzz. Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9016 llvm-svn: 235596
* Verify sizes when trying to read a BitcodeAbbrevOpFilipe Cabecinhas2015-04-233-0/+7
| | | | | | | | | | | | | | | | 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 llvm-svn: 235595
* Have more strict type checks when creating BinOp nodes in BitcodeReaderFilipe Cabecinhas2015-04-222-0/+5
| | | | | | | | | | | | Summary: Bug found with AFL. Reviewers: rafael, bkramer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9015 llvm-svn: 235489
* [opaque pointer type] Explicit pointee type for call instructionDavid Blaikie2015-04-173-0/+6
| | | | | | | | | | 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
* [opaque pointer type] Add textual IR support for explicit type parameter to ↵David Blaikie2015-04-161-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the call instruction See r230786 and r230794 for similar changes to gep and load respectively. Call is a bit different because it often doesn't have a single explicit type - usually the type is deduced from the arguments, and just the return type is explicit. In those cases there's no need to change the IR. When that's not the case, the IR usually contains the pointer type of the first operand - but since typed pointers are going away, that representation is insufficient so I'm just stripping the "pointerness" of the explicit type away. This does make the IR a bit weird - it /sort of/ reads like the type of the first operand: "call void () %x(" but %x is actually of type "void ()*" and will eventually be just of type "ptr". But this seems not too bad and I don't think it would benefit from repeating the type ("void (), void () * %x(" and then eventually "void (), ptr %x(") as has been done with gep and load. This also has a side benefit: since the explicit type is no longer a pointer, there's no ambiguity between an explicit type and a function that returns a function pointer. Previously this case needed an explicit type (eg: a function returning a void() function was written as "call void () () * @x(" rather than "call void () * @x(" because of the ambiguity between a function returning a pointer to a void() function and a function returning void). No ambiguity means even function pointer return types can just be written alone, without writing the whole function's type. This leaves /only/ the varargs case where the explicit type is required. Given the special type syntax in call instructions, the regex-fu used for migration was a bit more involved in its own unique way (as every one of these is) so here it is. Use it in conjunction with the apply.sh script and associated find/xargs commands I've provided in rr230786 to migrate your out of tree tests. Do let me know if any of this doesn't cover your cases & we can iterate on a more general script/regexes to help others with out of tree tests. About 9 test cases couldn't be automatically migrated - half of those were functions returning function pointers, where I just had to manually delete the function argument types now that we didn't need an explicit function type there. The other half were typedefs of function types used in calls - just had to manually drop the * from those. import fileinput import sys import re pat = re.compile(r'((?:=|:|^|\s)call\s(?:[^@]*?))(\s*$|\s*(?:(?:\[\[[a-zA-Z0-9_]+\]\]|[@%](?:(")?[\\\?@a-zA-Z0-9_.]*?(?(3)"|)|{{.*}}))(?:\(|$)|undef|inttoptr|bitcast|null|asm).*$)') addrspace_end = re.compile(r"addrspace\(\d+\)\s*\*$") func_end = re.compile("(?:void.*|\)\s*)\*$") def conv(match, line): if not match or re.search(addrspace_end, match.group(1)) or not re.search(func_end, match.group(1)): return line return line[:match.start()] + match.group(1)[:match.group(1).rfind('*')].rstrip() + match.group(2) + line[match.end():] for line in sys.stdin: sys.stdout.write(conv(re.search(pat, line), line)) llvm-svn: 235145
* [IR] Introduce a dereferenceable_or_null(N) attribute.Sanjoy Das2015-04-161-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Verify sizes when trying to read a VBR"Filipe Cabecinhas2015-04-152-5/+0
| | | | | | | This reverts r234984 since it seems to break some bots (most of them seemed arm*-selfhost). llvm-svn: 234998
OpenPOWER on IntegriCloud