(Re-apply r234361 with a fix and a testcase for PR23157)
Both run-time pointer checking and the dependence analysis are capable
of dealing with uniform addresses. I.e. it's really just an orthogonal
property of the loop that the analysis computes.
Run-time pointer checking will only try to reason about SCEVAddRec
pointers or else gives up. If the uniform pointer turns out the be a
SCEVAddRec in an outer loop, the run-time checks generated will be
correct (start and end bounds would be equal).
In case of the dependence analysis, we work again with SCEVs. When
compared against a loop-dependent address of the same underlying object,
the difference of the two SCEVs won't be constant. This will result in
returning an Unknown dependence for the pair.
When compared against another uniform access, the difference would be
constant and we should return the right type of dependence
(forward/backward/etc).
The changes also adds support to query this property of the loop and
modify the vectorizer to use this.
Patch by Ashutosh Nema!
llvm-svn: 234424
Both run-time pointer checking and the dependence analysis are capable
of dealing with uniform addresses. I.e. it's really just an orthogonal
property of the loop that the analysis computes.
Run-time pointer checking will only try to reason about SCEVAddRec
pointers or else gives up. If the uniform pointer turns out the be a
SCEVAddRec in an outer loop, the run-time checks generated will be
correct (start and end bounds would be equal).
In case of the dependence analysis, we work again with SCEVs. When
compared against a loop-dependent address of the same underlying object,
the difference of the two SCEVs won't be constant. This will result in
returning an Unknown dependence for the pair.
When compared against another uniform access, the difference would be
constant and we should return the right type of dependence
(forward/backward/etc).
The changes also adds support to query this property of the loop and
modify the vectorizer to use this.
Patch by Ashutosh Nema!
llvm-svn: 234361
The current crash reporting on Mac OS is only disabled via an environment variable.
This adds a boolean (default false) which can also disable crash reporting.
The only client right now is the unittests which don't ever want crash reporting, but do want to detect killed programs.
Reduces the time to run the APFloat unittests on my machine from
[----------] 47 tests from APFloatTest (51250 ms total)
to
[----------] 47 tests from APFloatTest (765 ms total)
Reviewed by Reid Kleckner and Justin Bogner
llvm-svn: 234353
Replace all uses of `DITypedArray<>` with `MDTupleTypedArrayWrapper<>`
and `MDTypeRefArray`. The APIs are completely different, but the
provided functionality is the same: treat an `MDTuple` as if it's an
array of a particular element type.
To simplify this patch a bit, I've temporarily typedef'ed
`DebugNodeArray` to `DIArray` and `MDTypeRefArray` to `DITypeArray`.
I've also temporarily conditionalized the accessors to check for null --
eventually these should be changed to asserts and the callers should
check for null themselves.
There's a tiny accompanying patch to clang.
llvm-svn: 234290
Remove special iterators from `DIExpression` in favour of same in
`MDExpression`. There should be no functionality change here.
Note that the APIs are slightly different: `getArg(unsigned)` counts
from 0, not 1, in the `MDExpression` version of the iterator.
llvm-svn: 234285
Move body of `DISubprogram::isPrivate()` (etc.) to `MDSubprogram`, and
change the versions in `DISubprogram` to forward there.
This is just like r234275, but for subprograms instead of types.
llvm-svn: 234282
Delete `DIDescriptor::is*()` and the various constructors from `MDNode*`
in `DIDescriptor` subclasses.
If this just broke your out-of-tree code, you need to make updates along
the lines of r234255, r234256, r234257 and r234258:
- Generally, `DIX().isX()` => `isa<MDX>()`. So, `D.isCompileUnit()`
should just be `isa<MDCompileUnit>(D)`, modulo checks for null.
- Exception: `DILexicalBlock` => `MDLexicalBlockBase`.
- Exception: `DIDerivedType` => `MDDerivedTypeBase`.
- Exception: `DICompositeType` => `MDCompositeTypeBase`.
- Exception: `DIVariable` => `MDLocalVariable`.
- Note that (e.g.) `DICompileUnit` has an implicit constructor from
`MDCompileUnit*`.
llvm-svn: 234263
`DIDescriptor`'s subclasses allow construction from incompatible
pointers, and `DIDescriptor` defines a series of `isa<>`-like functions
(e.g., `isCompileUnit()` instead of `isa<MDCompileUnit>()`) that clients
tend to use like this:
if (DICompileUnit(N).isCompileUnit())
foo(DICompileUnit(N));
These construction patterns work together to make `DIDescriptor` behave
differently from normal pointers.
Instead, use built-in `isa<>`, `dyn_cast<>`, etc., and only build
`DIDescriptor`s from pointers that are valid for their type.
I've split this into a few commits for different parts of LLVM and clang
(to decrease the patch size and increase the chance of review).
Generally the changes I made were NFC, but in a few places I made things
stricter if it made sense from the surrounded code.
Eventually a follow-up commit will remove the API for the "old" way.
llvm-svn: 234255
Allow LLVM-style casting on `DIDescriptor` and its subclasses so they
can behave more like raw pointers. I haven't bothered with tests since
I have a follow-up commit coming shortly that uses them extensively in
tree, and I'm hoping to kill `DIDescriptor` entirely before too long (so
they won't have time to bitrot).
Usage examples:
DIDescriptor D = foo();
if (DICompileUnit CU = dyn_cast<MDCompileUnit>(D))
return bar(CU);
else if (auto *SP = dyn_cast<MDSubprogram>(D))
return baz(SP);
return other(D);
llvm-svn: 234250
Gut `DIRef<>::resolve()`, reimplementing it using
`TypedDebugNodeRef<>::resolve()`. Use three separate functions rather
than some sort of type traits, since the latter (i.e., mapping `DIScope`
=> `MDScope`) seems heavy-handed. I don't expect `DIRef<>` to last much
longer in tree anyway.
As a drive-by fix, make `TypedDebugNodeRef<>::resolve()` do the right
thing with `nullptr`.
llvm-svn: 234248
Remove `DILexicalBlockFile::getScope()` (whose last use was removed from
clang in r234245), which illegally returned a `DILexicalBlock` despite
its scope sometimes being an `MDSubprogram`. Also remove the
`getLineNumber()` and `getColumnNumber()` methods that just forwarded to
`DILexicalBlock`'s versions, since there don't seem to be any callers.
Note that the block of code removed from `DebugInfo.cpp` was actually
dead code, since `isLexicalBlock()` (the previous branch) always returns
true when `isLexicalBlockFile()` returns true.
An earlier (broken and untested) version of this was squashed into
r234222 and reverted in r234225.
llvm-svn: 234246
This reverts commit r234225, reapplying r234222 in spirit.
This time, just include what the commit message actually describes:
loosen the `DILexicalBlock` constructor to require a
`MDLexicalBlockBase`, since that's what `DILexicalBlock` is wrapping.
llvm-svn: 234241
This class wraps `MDLexicalBlockBase`, so allow construction from it!
Currently doesn't cause any problems because of the explicit `MNode*`
constructor, but I'll be removing that soon enough.
llvm-svn: 234222
Summary:
Instead of making a local copy of `checkInterfaceFunction` for each
sanitizer, move the function in a common place.
Reviewers: kcc, samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8775
llvm-svn: 234220
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
Remove `DIDescriptor::Verify()` and the `Verify()`s from subclasses.
They had already been gutted, and just did an `isa<>` check.
In a couple of cases I've temporarily dropped the check entirely, but
subsequent commits are going to disallow conversions to the
`DIDescriptor`s directly from `MDNode`, so the checks will come back in
another form soon enough.
llvm-svn: 234201
This array-like wrapper adapts `MDTuple` to have elements of `MDTypeRef`
(whereas `MDTypeArray` has elements of `MDType`). This is necessary to
migrate code using `DITypeArray`. The only use of this is
`MDSubroutineType`'s `getTypeArray()` accessor.
llvm-svn: 234200
Use `MDTypeRef` (etc.) in the new debug info hierarchy rather than raw
`Metadata *` pointers.
I rolled in a change to `DIBuilder` that looks unrelated: take `DIType`
instead of `DITypeRef` as type arguments when creating variables.
However, this was the simplest way to use `MDTypeRef` within the
functions, and didn't require any cleanups from callers in clang (since
they were all passing in `DIType`s anyway, relying on their implicit
conversions to `DITypeRef`).
llvm-svn: 234197
Add `MDTupleTypedArrayWrapper`, a wrapper around `MDTuple` that adapts
it to look like an array and cast its operands to the given type. This
is designed to be a replacement for `DITypedArray<>`, which is in the
`DIDescriptor` hierarchy.
llvm-svn: 234183
