summaryrefslogtreecommitdiffstats
path: root/llvm/lib/AsmParser
Commit message (Collapse)AuthorAgeFilesLines
...
* [opaque pointer type] Pass the explicit function type down to the ↵David Blaikie2015-05-131-1/+1
| | | | | | instruction constructor when parsing invoke instructions llvm-svn: 237273
* [opaque pointer type] Pass GlobalAlias the actual pointer type rather than ↵David Blaikie2015-04-291-4/+2
| | | | | | | | | | | | | decomposing it into pointee type + address space Many of the callers already have the pointer type anyway, and for the couple of callers that don't it's pretty easy to call PointerType::get on the pointee type and address space. This avoids LLParser from using PointerType::getElementType when parsing GlobalAliases from IR. llvm-svn: 236160
* IR: Give 'DI' prefix to debug info metadataDuncan P. N. Exon Smith2015-04-291-83/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* IR: Add assembly/bitcode support for function metadata attachmentsDuncan P. N. Exon Smith2015-04-242-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* LLParser: Simplify ParseInstructionMetadata(), NFCDuncan P. N. Exon Smith2015-04-242-7/+6
| | | | | | | | Remove unused `PFS` variable and take the `Instruction` by reference. (Not really related to PR23340, but might as well clean this up while I'm here.) llvm-svn: 235782
* LLParser: Split out ParseMetadataAttachment(), NFCDuncan P. N. Exon Smith2015-04-242-5/+15
| | | | | | Make the code reusable for `Function` metadata attachments (PR23340). llvm-svn: 235778
* [opaque pointer type] Add textual IR support for explicit type parameter to ↵David Blaikie2015-04-241-6/+4
| | | | | | | | | | the invoke instruction Same as r235145 for the call instruction - the justification, tradeoffs, etc are all the same. The conversion script worked the same without any false negatives (after replacing 'call' with 'invoke'). llvm-svn: 235755
* Recommit r235458: [opaque pointer type] Avoid using ↵David Blaikie2015-04-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 235651
* Revert "[opaque pointer type] Avoid using PointerType::getElementType for a ↵David Blaikie2015-04-221-1/+1
| | | | | | | | | | | 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. llvm-svn: 235533
* [opaque pointer type] Use pointee type retrieved from asm, rather than ↵David Blaikie2015-04-221-2/+1
| | | | | | accessing it via the pointer type llvm-svn: 235520
* [opaque pointer type] Avoid using PointerType::getElementType for a few ↵David Blaikie2015-04-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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) llvm-svn: 235458
* [opaque pointer type] Use the parsed explicit pointee type when ↵David Blaikie2015-04-171-5/+2
| | | | | | error-checking geps during LL parsing llvm-svn: 235233
* [opaque pointer type] Add textual IR support for explicit type parameter to ↵David Blaikie2015-04-161-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-164-7/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* DebugInfo: Remove 'inlinedAt:' field from MDLocalVariableDuncan P. N. Exon Smith2015-04-151-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove empty non-virtual destructors or mark them =default when non-publicBenjamin Kramer2015-04-111-1/+0
| | | | | | These add no value but can make a class non-trivially copyable. NFC. llvm-svn: 234688
* DebugInfo: Move DIFlag-related API from DIDescriptor to DebugNodeDuncan P. N. Exon Smith2015-04-071-1/+1
| | | | llvm-svn: 234274
* [opaque pointer type] Avoid using PointerType::getElementType when parsing IRDavid Blaikie2015-04-061-4/+3
| | | | | | | | | | A few calls are left in for error checking - but I'm commenting those out & trying to build some IR tests (aiming for Argument Promotion to start with). When I get any of these tests passing I may add flag to disable the checking so I can add tests that pass with the assertion in place. llvm-svn: 234206
* [opaque pointer type] API migration for GEP constant factoriesDavid Blaikie2015-04-021-6/+3
| | | | | | | | | | | | | 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. llvm-svn: 233938
* Verifier: Move more debug info checks away from Verify()Duncan P. N. Exon Smith2015-03-311-2/+8
| | | | | | | | | | Most of these checks were already in the `Verifier` so this is more of a cleanup. Now almost everything is over there. Now that require a `name:` for `MDGlobalVariable`, add a check in `LLParser` for it. llvm-svn: 233657
* Verifier: Move checks over from DIDescriptor::Verify()Duncan P. N. Exon Smith2015-03-311-1/+1
| | | | | | | | | | | | | | Move over some more checks from `DIDescriptor::Verify()`, and change `LLParser` to require non-null `file:` fields in compile units. I've ignored the comment in test/Assembler/metadata-null-operands.ll since I disagree with it. At the time that test was written (r229960), the debug info verifier wasn't on by default, so my comment there is in the context of not expecting the verifier to be useful. It is now, and besides that, since r233394 we can check when parsing textual IR whether an operand is null that shouldn't be. llvm-svn: 233654
* [opaque pointer type] Change GetElementPtrInst::getIndexedType to take the ↵David Blaikie2015-03-301-2/+7
| | | | | | | | | | pointee type This pushes the use of PointerType::getElementType up into several callers - I'll essentially just have to keep pushing that up the stack until I can eliminate every call to it... llvm-svn: 233604
* Verifier: Add operand checks for MDLexicalBlockDuncan P. N. Exon Smith2015-03-301-2/+2
| | | | | | | | | | Add operand checks for `MDLexicalBlock` and `MDLexicalBlockFile`. Like `MDLocalVariable` and `MDLocation`, these nodes always require a scope. There was no test bitrot to fix here (just updated the serialization tests in test/Assembler/mdlexicalblock.ll). llvm-svn: 233561
* LLParser: Require non-null scope for MDLocation and MDLocalVariableDuncan P. N. Exon Smith2015-03-271-3/+7
| | | | | | | | | Change `LLParser` to require a non-null `scope:` field for both `MDLocation` and `MDLocalVariable`. There's no need to wait for the verifier for this check. This also allows their `::getImpl()` methods to assert that the incoming scope is non-null. llvm-svn: 233394
* Verifier: Check fields of MDVariable subclassesDuncan P. N. Exon Smith2015-03-271-4/+4
| | | | | | | | | | | | | | | | Check fields from `MDLocalVariable` and `MDGlobalVariable` and change the accessors to downcast to the right types. `getType()` still returns `Metadata*` since it could be an `MDString`-based reference. Since local variables require non-null scopes, I also updated `LLParser` to require a `scope:` field. A number of testcases had grown bitrot and started failing with this patch; I committed them separately in r233349. If I just broke your out-of-tree testcases, you're probably hitting similar problems (so have a look there). llvm-svn: 233389
* Verifier: Check accessors of MDLocationDuncan P. N. Exon Smith2015-03-261-2/+2
| | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 233322
* AsmParser: Stop requiring 'name:' when it's not printedDuncan P. N. Exon Smith2015-03-161-3/+3
| | | | | | | | | r230877 optimized which fields are written out for `CHECK`-ability, but apparently missed changing some of them to optional in `LLParser`. Fixes PR22921. llvm-svn: 232400
* [opaque pointer type] more gep API migrations (AsmParser)David Blaikie2015-03-141-1/+1
| | | | llvm-svn: 232276
* [opaque pointer type] Add textual IR support for explicit type parameter to ↵David Blaikie2015-03-131-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gep operator Similar to gep (r230786) and load (r230794) changes. Similar migration script can be used to update test cases, which successfully migrated all of LLVM and Polly, but about 4 test cases needed manually changes in Clang. (this script will read the contents of stdin and massage it into stdout - wrap it in the 'apply.sh' script shown in previous commits + xargs to apply it over a large set of test cases) import fileinput import sys import re rep = re.compile(r"(getelementptr(?:\s+inbounds)?\s*\()((<\d*\s+x\s+)?([^@]*?)(|\s*addrspace\(\d+\))\s*\*(?(3)>)\s*)(?=$|%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|zeroinitializer|<|\[\[[a-zA-Z]|\{\{)", re.MULTILINE | re.DOTALL) def conv(match): line = match.group(1) line += match.group(4) line += ", " line += match.group(2) return line line = sys.stdin.read() off = 0 for match in re.finditer(rep, line): sys.stdout.write(line[off:match.start()]) sys.stdout.write(conv(match)) off = match.end() sys.stdout.write(line[off:]) llvm-svn: 232184
* Fix a stack overflow in the assembler when checking that GEPs must be over ↵Owen Anderson2015-03-101-2/+6
| | | | | | | | | sized types. We failed to use a marking set to properly handle recursive types, which caused use to recurse infinitely and eventually overflow the stack. llvm-svn: 231760
* LLParser: gep: Simplify parsing error handlingDavid Blaikie2015-03-091-10/+4
| | | | llvm-svn: 231722
* Fix a bug in the LLParser where we failed to diagnose landingpads with ↵Owen Anderson2015-03-091-6/+7
| | | | | | | | | | non-constant clause operands. Fixing this also exposed a related issue where the landingpad under construction was not cleaned up when an error was raised, which would cause bad reference errors before the error could actually be printed. llvm-svn: 231634
* Revert "unique_ptrify ValID::ConstantStructElts"Reid Kleckner2015-03-042-17/+11
| | | | | | | | | | | | | | | | | | | | | This reverts r231200 and r231204. The second one added an explicit move ctor for MSVC. This change broke the clang-cl self-host due to weirdness in MSVC's implementation of std::map::insert. Somehow we lost our rvalue ref-ness when going through variadic placement new: template <class _Objty, class... _Types> void construct(_Objty *_Ptr, _Types &&... _Args) { // construct _Objty(_Types...) at _Ptr ::new ((void *)_Ptr) _Objty(_STD forward<_Types>(_Args)...); } For some reason, Clang decided to call the deleted std::pair copy constructor at this point. Needs further investigation, once I can build. llvm-svn: 231269
* Workaround MSVC not providing implicit move membersDavid Blaikie2015-03-041-0/+8
| | | | llvm-svn: 231204
* unique_ptrify ValID::ConstantStructEltsDavid Blaikie2015-03-042-11/+9
| | | | llvm-svn: 231200
* LLParser: Avoid copying ValIDs, the copy ctor is deprecated in C++11 due to ↵David Blaikie2015-03-041-1/+6
| | | | | | the presence of a user-declared dtor llvm-svn: 231199
* Revert "Remove the explicit SDNodeIterator::operator= in favor of the ↵David Blaikie2015-03-032-13/+12
| | | | | | | | | | | implicit default" Accidentally committed a few more of these cleanup changes than intended. Still breaking these out & tidying them up. This reverts commit r231135. llvm-svn: 231136
* Remove the explicit SDNodeIterator::operator= in favor of the implicit defaultDavid Blaikie2015-03-032-12/+13
| | | | | | | | | | There doesn't seem to be any need to assert that iterator assignment is between iterators over the same node - if you want to reuse an iterator variable to iterate another node, that's perfectly acceptable. Just don't mix comparisons between iterators into disjoint sequences, as usual. llvm-svn: 231135
* Cleanup after r230934 per Dave's suggestions.Owen Anderson2015-03-031-3/+4
| | | | llvm-svn: 231056
* Teach the LLParser to fail gracefully when it encounters an invalid label name.Owen Anderson2015-03-021-5/+7
| | | | | | Previous it would either assert in +Asserts, or crash in -Asserts. Found by fuzzing LLParser. llvm-svn: 230935
* Fix a crash in the LL parser where it failed to validate that the pointer ↵Owen Anderson2015-03-021-0/+2
| | | | | | | | operand of a GEP was valid. This manifested as an assertion failure in +Asserts builds, and a hard crash in -Asserts builds. Found by fuzzing the LL parser. llvm-svn: 230934
* Add missing includes. make_unique proliferated everywhere.Benjamin Kramer2015-03-011-0/+1
| | | | llvm-svn: 230909
* Optimize metadata node fields for CHECK-abilityDuncan P. N. Exon Smith2015-02-281-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While gaining practical experience hand-updating CHECK lines (for moving the new debug info hierarchy into place), I learnt a few things about CHECK-ability of the specialized node assembly output. - The first part of a `CHECK:` is to identify the "right" node (this is especially true if you intend to use the new `CHECK-SAME` feature, since the first CHECK needs to identify the node correctly before you can split the line). - If there's a `tag:`, it should go first. - If there's a `name:`, it should go next (followed by the `linkageName:`, if any). - If there's a `scope:`, it should follow after that. - When a node type supports multiple DW_TAGs, but one is implied by its name and is overwhelmingly more common, the `tag:` field is terribly uninteresting unless it's different. - `MDBasicType` is almost always `DW_TAG_base_type`. - `MDTemplateValueParameter` is almost always `DW_TAG_template_value_parameter`. - Printing `name: ""` doesn't improve CHECK-ability, and there are far more nodes than I realized that are commonly nameless. - There are a few other fields that similarly aren't very interesting when they're empty. This commit updates the `AsmWriter` as suggested above (and makes necessary changes in `LLParser` for round-tripping). llvm-svn: 230877
* [opaque pointer type] Add textual IR support for explicit type parameter to ↵David Blaikie2015-02-271-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 llvm-svn: 230794
* [opaque pointer type] Add textual IR support for explicit type parameter to ↵David Blaikie2015-02-271-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | getelementptr instruction One of several parallel first steps to remove the target type of pointers, replacing them with a single opaque pointer type. This adds an explicit type parameter to the gep instruction so that when the first parameter becomes an opaque pointer type, the type to gep through is still available to the instructions. * This doesn't modify gep operators, only instructions (operators will be handled separately) * Textual IR changes only. Bitcode (including upgrade) and changing the in-memory representation will be in separate changes. * geps of vectors are transformed as: getelementptr <4 x float*> %x, ... ->getelementptr float, <4 x float*> %x, ... Then, once the opaque pointer type is introduced, this will ultimately look like: getelementptr float, <4 x ptr> %x with the unambiguous interpretation that it is a vector of pointers to float. * address spaces remain on the pointer, not the type: getelementptr float addrspace(1)* %x ->getelementptr float, float addrspace(1)* %x Then, eventually: getelementptr float, ptr addrspace(1) %x Importantly, the massive amount of test case churn has been automated by same crappy python code. I had to manually update a few test cases that wouldn't fit the script's model (r228970,r229196,r229197,r229198). The python script just massages stdin and writes the result to stdout, I then wrapped that in a shell script to handle replacing files, then using the usual find+xargs to migrate all the files. update.py: import fileinput import sys import re ibrep = re.compile(r"(^.*?[^%\w]getelementptr inbounds )(((?:<\d* x )?)(.*?)(| addrspace\(\d\)) *\*(|>)(?:$| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$))") normrep = re.compile( r"(^.*?[^%\w]getelementptr )(((?:<\d* x )?)(.*?)(| addrspace\(\d\)) *\*(|>)(?:$| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$))") def conv(match, line): if not match: return line line = match.groups()[0] if len(match.groups()[5]) == 0: line += match.groups()[2] line += match.groups()[3] line += ", " line += match.groups()[1] line += "\n" return line for line in sys.stdin: if line.find("getelementptr ") == line.find("getelementptr inbounds"): if line.find("getelementptr inbounds") != line.find("getelementptr inbounds ("): line = conv(re.match(ibrep, line), line) elif line.find("getelementptr ") != line.find("getelementptr ("): line = conv(re.match(normrep, line), line) sys.stdout.write(line) apply.sh: for name in "$@" do python3 `dirname "$0"`/update.py < "$name" > "$name.tmp" && mv "$name.tmp" "$name" rm -f "$name.tmp" done The actual commands: From llvm/src: find test/ -name *.ll | xargs ./apply.sh From llvm/src/tools/clang: find test/ -name *.mm -o -name *.m -o -name *.cpp -o -name *.c | xargs -I '{}' ../../apply.sh "{}" From llvm/src/tools/polly: find test/ -name *.ll | xargs ./apply.sh After that, check-all (with llvm, clang, clang-tools-extra, lld, compiler-rt, and polly all checked out). The extra 'rm' in the apply.sh script is due to a few files in clang's test suite using interesting unicode stuff that my python script was throwing exceptions on. None of those files needed to be migrated, so it seemed sufficient to ignore those cases. Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7636 llvm-svn: 230786
* AsmParser: Check ConstantExpr insertvalue operands for type correctnessDavid Majnemer2015-02-231-1/+8
| | | | llvm-svn: 230206
* AsmParser: Call instructions can't have an alignmentDavid Majnemer2015-02-231-2/+10
| | | | llvm-svn: 230193
* AsmParser: Check ConstantExpr GEP operands for validityDavid Majnemer2015-02-221-2/+24
| | | | llvm-svn: 230188
* AsmParser/Writer: Handle symbolic constants in DI 'flags:'Duncan P. N. Exon Smith2015-02-213-5/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | Parse (and write) symbolic constants in debug info `flags:` fields. This prevents a readability (and CHECK-ability) regression with the new debug info hierarchy. Old (well, current) assembly, with pretty-printing: !{!"...\\0016387", ...} ; ... [public] [rvalue reference] Flags field without this change: !MDDerivedType(flags: 16387, ...) Flags field with this change: !MDDerivedType(flags: DIFlagPublic | DIFlagRValueReference, ...) As discussed in the review thread, this isn't a final state. Most of these flags correspond to `DW_AT_` symbolic constants, and we might eventually want to support arbitrary attributes in some form. However, as it stands now, some of the flags correspond to other concepts (like `FlagStaticMember`); until things are refactored this is the simplest way to move forward without regressing assembly. llvm-svn: 230111
* AsmParser: Use StringRef for keyword comparisons, NFCDuncan P. N. Exon Smith2015-02-211-10/+9
| | | | | | | | Leverage `StringRef` inside keyword comparison macros. There's no reason to be so low-level here, and I'm about to add another `startswith()` use, so let's make it easy to read. llvm-svn: 230100
OpenPOWER on IntegriCloud