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
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
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
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
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
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
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
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
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
`do { ... } while (false)` is standard macro etiquette for forcing
instantiations into a single statement and requiring a `;` afterwards,
making statement-like macros easier to reason about (and harder to use
incorrectly).
I'm about to modify the macros in `LexIdentifier()`. I noticed that the
`KEYWORD` macro *does* follow the rule, so I thought I'd clean up the
other macros to match (otherwise might not be worth changing, since the
benefits of this pattern are fairly irrelevant here).
llvm-svn: 230095
When trying to match the current schema with the new debug info
hierarchy, I downgraded `SizeInBits`, `AlignInBits` and `OffsetInBits`
to 32-bits (oops!). Caught this while testing my upgrade script to move
the hierarchy into place. Bump it back up to 64-bits and update tests.
llvm-svn: 229933
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
It turns out that `count: -1` is a special value indicating an empty
array, such as `Values` in:
struct T {
unsigned Count;
int Values[];
};
Handle it.
llvm-svn: 229769
Put the name before the value in assembly for `MDEnum`. While working
on the testcase upgrade script for the new hierarchy, I noticed that it
"looks nicer" to have the name first, since it lines the names up in the
(somewhat typical) case that they have a common prefix.
llvm-svn: 229747
David Blaikie