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
We don't have any logic to emit those tables yet, so the sdag lowering
of this intrinsic is just a stub. We can see the intrinsic in the
prepared IR, though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233209 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds Hardware Transaction Memory (HTM) support supported by ISA 2.07
(POWER8). The intrinsic support is based on GCC one [1], but currently only the
'PowerPC HTM Low Level Built-in Function' are implemented.
The HTM instructions follows the RC ones and the transaction initiation result
is set on RC0 (with exception of tcheck). Currently approach is to create a
register copy from CR0 to GPR and comapring. Although this is suboptimal, since
the branch could be taken directly by comparing the CR0 value, it generates code
correctly on both test and branch and just return value. A possible future
optimization could be elimitate the MFCR instruction to branch directly.
The HTM usage requires a recently newer kernel with PPC HTM enabled. Tested on
powerpc64 and powerpc64le.
This is send along a clang patch to enabled the builtins and option switch.
[1] https://gcc.gnu.org/onlinedocs/gcc/PowerPC-Hardware-Transactional-Memory-Built-in-Functions.html
Phabricator Review: http://reviews.llvm.org/D8247
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233204 91177308-0d34-0410-b5e6-96231b3b80d8
Move definition of `MDLocation` after `MDLocalScope` so that the latter
is available for casts in the former. Similarly, move the definition of
`MDFile` as early as possible so that other classes can cast to it in
their definitions. (Follow-up commits will take advantage of this.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233096 91177308-0d34-0410-b5e6-96231b3b80d8
Add a subclass of `MDScope` to explicitly categorize the legal scopes
for locals -- in particular, scopes that are legal for `MDLocation`,
`MDLexicalBlockBase`, and `MDLocalVariable`. This provides a convenient
`isa<>` target for the verifier, and eventually I'll be changing the
above classes' `getScope()` to specifically return it. Currently, its
subclasses are `MDSubprogram`, `MDLexicalBlock`, and
`MDLexicalBlockFile`.
I've gone with `MDLocalScope` for now -- a little ambiguous since it's a
scope *for* locals, not a scope that's local -- but I'm open to more
descriptive names if someone can think of something better. Regardless,
the code docs should make it clear enough.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233092 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Previous behaviour of 'R' and 'm' has been preserved for now. They will be
improved in subsequent commits.
The offset permitted by ZC varies according to the subtarget since it is
intended to match the restrictions of the pref, ll, and sc instructions.
The restrictions on these instructions are:
* For microMIPS: 12-bit signed offset.
* For Mips32r6/Mips64r6: 9-bit signed offset.
* Otherwise: 16-bit signed offset.
Reviewers: vkalintiris
Reviewed By: vkalintiris
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8414
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233063 91177308-0d34-0410-b5e6-96231b3b80d8
Continue to simplify the `DIDescriptor` subclasses, so that they behave
more like raw pointers. Remove `getRaw()`, replace it with an
overloaded `get()`, and overload the arrow and cast operators. Two
testcases started to crash on the arrow operators with this change
because of `scope:` references that weren't real scopes. I fixed them.
Soon I'll add verifier checks for them too.
This also adds explicit dereference operators. Previously, the builtin
dereference against `operator MDNode *()` would have worked, but now the
builtins are ambiguous.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233030 91177308-0d34-0410-b5e6-96231b3b80d8
As part of PR22777, switch from `dyn_cast_or_null<>` to `cast<>` in most
`DIDescriptor` accessors. These classes are lightweight wrappers around
pointers, so the users should check for valid pointers before using
them.
This survives a Darwin clang -g bootstrap (after fixing testcases), but
it's possible the bots will complain about other configurations. I'll
fix any fallout as quickly as I can! Once this bakes for a bit I'll
remove the macros.
Note that `DebugLoc` implicitly gets stricter with this change as well,
since it forward to `DILocation`. Any code that's using `DebugLoc`
accessors should check `DebugLoc::isUnknown()` first. (BTW, I'm also
partway through a cleanup of the `DebugLoc` API to make it more obvious
what it is (a glorified pointer wrapper) and remove cruft from before
the Metadata/Value split. I'll commit soon.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232844 91177308-0d34-0410-b5e6-96231b3b80d8
Remove `DebugInfoVerifierLegacyPass` and the `-verify-di` pass.
Instead, call into the `DebugInfoVerifier` from inside
`VerifierLegacyPass::finalizeModule()`. This better matches the logic
in `verifyModule()` (used by the new PassManager), avoids requiring two
separate passes to verify the IR, and makes the API for "add a pass to
verify the IR" simple.
Note: the `-verify-debug-info` flag still works (for now, at least;
eventually it might make sense to just remove it).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232772 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change splits `makeICmpRegion` into `makeAllowedICmpRegion` and
`makeSatisfyingICmpRegion` with slightly different contracts. The first
one is useful for determining what values some expression //may// take,
given that a certain `icmp` evaluates to true. The second one is useful
for determining what values are guaranteed to //satisfy// a given
`icmp`.
Reviewers: nlewycky
Reviewed By: nlewycky
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8345
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232575 91177308-0d34-0410-b5e6-96231b3b80d8
COFF COMDATs (for selection kinds other than 'select any') require at
least one non-section symbol in the symbol table.
Satisfy this by morally enhancing the linkage from private to internal.
Differential Revision: http://reviews.llvm.org/D8394
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232570 91177308-0d34-0410-b5e6-96231b3b80d8
Break MDExpression off of DebugNode (inherit directly from `MDNode`) and
drop the fake `DW_TAG_expression` tag in the process.
AFAICT, there's no real functionality change here. The tag was
originally used by `DIDescriptor::isExpression()` to discriminate
between `MDNode`s, but in the new hierarchy we don't need that.
Fixes PR22780.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232550 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
But still handle them the same way since I don't know how they differ on
this target.
No functional change intended.
Reviewers: uweigand
Reviewed By: uweigand
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8251
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232495 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
But still handle them the same way since I don't know how they differ on
this target.
No functional change intended.
Reviewers: kparzysz, adasgupt
Reviewed By: kparzysz, adasgupt
Subscribers: colinl, llvm-commits
Differential Revision: http://reviews.llvm.org/D8204
Like for the PowerPC target, I've had to add 'i' to the constraint mappings in
order to pass 2007-12-17-InvokeAsm.ll. It's not clear why 'i' has historically
been treated as a memory constraint.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232480 91177308-0d34-0410-b5e6-96231b3b80d8
It's not completely clear why 'i' has historically been treated as a memory
constraint. According to the documentation, it represents a constant immediate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232470 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
But still handle them the same way since I don't know how they differ on
this target.
Of these, 'es', and 'Q' do not have backend tests but are accepted by
clang.
No functional change intended. Depends on D8173.
Reviewers: hfinkel
Reviewed By: hfinkel
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8213
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232466 91177308-0d34-0410-b5e6-96231b3b80d8
Now that we check `MDExpression` during `-verify` (r232299), make
the `DIExpression` wrapper more strict:
- remove redundant checks in `DebugInfoVerifier`,
- overload `get()` to `cast_or_null<MDExpression>` (superseding
`getRaw()`),
- stop checking for null in any accessor, and
- remove `DIExpression::Verify()` entirely in favour of
`MDExpression::isValid()`.
There is still some logic in this class, mostly to do with high-level
iterators; I'll defer cleaning up those until the rest of the wrappers
are similarly strict.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232412 91177308-0d34-0410-b5e6-96231b3b80d8
This covers essentially all of llvm's headers and libs. One or two weird
cases I wasn't sure were worth/appropriate to fix.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232394 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
But still handle them the same way since I don't know how they differ on
this target.
No functional change intended.
Reviewers: kparzysz, adasgupt
Reviewed By: kparzysz, adasgupt
Subscribers: colinl, llvm-commits
Differential Revision: http://reviews.llvm.org/D8204
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232374 91177308-0d34-0410-b5e6-96231b3b80d8
Use an overload instead of a default argument for `Metadata::dump()`.
The latter seems to require calling `dump(nullptr)` explicitly when
using a debugger, where as the former doesn't.
Other than utility for debugging, there's NFC here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232315 91177308-0d34-0410-b5e6-96231b3b80d8
Change accessors to downcast to `MDLocalVariable` and `MDExpression`,
now that we have -verify checks in place to confirm that it's safe.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232299 91177308-0d34-0410-b5e6-96231b3b80d8
Verify that debug info intrinsic arguments are valid. (These checks
will not recurse through the full debug info graph, so they don't need
to be cordoned of in `DebugInfoVerifier`.)
With those checks in place, changing the `DbgIntrinsicInst` accessors to
downcast to `MDLocalVariable` and `MDExpression` is natural (added isa
specializations in `Metadata.h` to support this).
Added tests to `test/Verifier` for the new -verify checks, and fixed the
debug info in all the in-tree tests.
If you have out-of-tree testcases that have started to fail to -verify,
hopefully the verify checks are helpful. The most likely problem is
that the expression argument is `!{}` (instead of `!MDExpression()`).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232296 91177308-0d34-0410-b5e6-96231b3b80d8
This concludes the GetElementPtrInst::Create migration, thus marking the
beginning of the IRBuilder::CreateGEP* migration to come.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232280 91177308-0d34-0410-b5e6-96231b3b80d8
Replumb the `AsmWriter` so that `Metadata::print()` is generally useful.
(Similarly change `Metadata::printAsOperand()`.)
- `SlotTracker` now has a mode where all metadata will be correctly
numbered when initializing a `Module`. Normally, `Metadata` only
referenced from within `Function`s gets numbered when the `Function`
is incorporated.
- `Metadata::print()` and `Metadata::printAsOperand()` (and
`Metadata::dump()`) now take an optional `Module` argument. When
provided, `SlotTracker` is initialized with the new mode, and the
numbering will be complete and consistent for all calls to `print()`.
- `Value::print()` uses the new `SlotTracker` mode when printing
intrinsics with `MDNode` operands, `MetadataAsValue` operands, or the
bodies of functions. Thus, metadata numbering will be consistent
between calls to `Metadata::print()` and `Value::print()`.
- `Metadata::print()` (and `Metadata::dump()`) now print the full
definition of `MDNode`s:
!5 = !{!6, !"abc", !7}
This matches behaviour for `Value::print()`, which includes the name
of instructions.
- Updated call sites in `Verifier` to call `print()` instead of
`printAsOperand()`.
All this, so that `Verifier` can print out useful failure messages that
involve `Metadata` for PR22777.
Note that `Metadata::printAsOperand()` previously took an optional
`bool` and `Module` operand. The former was cargo-culted from
`Value::printAsOperand()` and wasn't doing anything useful. The latter
didn't give consistent results (without the new `SlotTracker` mode).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232275 91177308-0d34-0410-b5e6-96231b3b80d8
Adding nullptr to all the IRBuilder stuff because it's the first thing
that fails to build when testing without the back-compat functions, so
I'll keep having to re-add these locally for each chunk of migration I
do. Might as well check them in to save me the churn. Eventually I'll
have to migrate these too, but I'm going breadth-first.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232270 91177308-0d34-0410-b5e6-96231b3b80d8
I'm just going to migrate these in a pretty ad-hoc & incremental way -
providing the backwards compatible API for now, then locally removing
it, fixing a few callers, adding it back in and commiting those callers.
Rinse, repeat.
The assertions should ensure that if I get this wrong we'll find out
about it and not just have one giant patch to revert, recommit, revert,
recommit, etc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232240 91177308-0d34-0410-b5e6-96231b3b80d8
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
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
The operand flag word for ISD::INLINEASM nodes now contains a 15-bit
memory constraint ID when the operand kind is Kind_Mem. This constraint
ID is a numeric equivalent to the constraint code string and is converted
with a target specific hook in TargetLowering.
This patch maps all memory constraints to InlineAsm::Constraint_m so there
is no functional change at this point. It just proves that using these
previously unused bits in the encoding of the flag word doesn't break
anything.
The next patch will make each target preserve the current mapping of
everything to Constraint_m for itself while changing the target independent
implementation of the hook to return Constraint_Unknown appropriately. Each
target will then be adapted in separate patches to use appropriate
Constraint_* values.
PR22883 was caused the matching operands copying the whole of the operand flags
for the matched operand. This included the constraint id which needed to be
replaced with the operand number. This has been fixed with a conversion
function. Following on from this, matching operands also used the operand
number as the constraint id. This has been fixed by looking up the matched
operand and taking it from there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232165 91177308-0d34-0410-b5e6-96231b3b80d8
This should complete the job started in r231794 and continued in r232045:
We want to replace as much custom x86 shuffling via intrinsics
as possible because pushing the code down the generic shuffle
optimization path allows for better codegen and less complexity
in LLVM.
AVX2 introduced proper integer variants of the hacked integer insert/extract
C intrinsics that were created for this same functionality with AVX1.
This should complete the removal of insert/extract128 intrinsics.
The Clang precursor patch for this change was checked in at r232109.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232120 91177308-0d34-0410-b5e6-96231b3b80d8
This (r232027) has caused PR22883; so it seems those bits might be used by
something else after all. Reverting until we can figure out what else to do.
Original commit message:
The operand flag word for ISD::INLINEASM nodes now contains a 15-bit
memory constraint ID when the operand kind is Kind_Mem. This constraint
ID is a numeric equivalent to the constraint code string and is converted
with a target specific hook in TargetLowering.
This patch maps all memory constraints to InlineAsm::Constraint_m so there
is no functional change at this point. It just proves that using these
previously unused bits in the encoding of the flag word doesn't break anything.
The next patch will make each target preserve the current mapping of
everything to Constraint_m for itself while changing the target independent
implementation of the hook to return Constraint_Unknown appropriately. Each
target will then be adapted in separate patches to use appropriate Constraint_*
values.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232093 91177308-0d34-0410-b5e6-96231b3b80d8
Now that we've replaced the vinsertf128 intrinsics,
do the same for their extract twins.
This is very much like D8086 (checked in at r231794):
We want to replace as much custom x86 shuffling via intrinsics
as possible because pushing the code down the generic shuffle
optimization path allows for better codegen and less complexity
in LLVM.
This is also the LLVM sibling to the cfe D8275 patch.
Differential Revision: http://reviews.llvm.org/D8276
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232045 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The operand flag word for ISD::INLINEASM nodes now contains a 15-bit
memory constraint ID when the operand kind is Kind_Mem. This constraint
ID is a numeric equivalent to the constraint code string and is converted
with a target specific hook in TargetLowering.
This patch maps all memory constraints to InlineAsm::Constraint_m so there
is no functional change at this point. It just proves that using these
previously unused bits in the encoding of the flag word doesn't break anything.
The next patch will make each target preserve the current mapping of
everything to Constraint_m for itself while changing the target independent
implementation of the hook to return Constraint_Unknown appropriately. Each
target will then be adapted in separate patches to use appropriate Constraint_*
values.
Reviewers: hfinkel
Reviewed By: hfinkel
Subscribers: hfinkel, jholewinski, llvm-commits
Differential Revision: http://reviews.llvm.org/D8171
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232027 91177308-0d34-0410-b5e6-96231b3b80d8
These docs *don't* match the way WinEHPrepare uses them yet, and
verifier support isn't implemented either. The implementation will come
after the documentation text is reviewed and agreed upon.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232003 91177308-0d34-0410-b5e6-96231b3b80d8
We want to replace as much custom x86 shuffling via intrinsics
as possible because pushing the code down the generic shuffle
optimization path allows for better codegen and less complexity
in LLVM.
This is the sibling patch for the Clang half of this change:
http://reviews.llvm.org/D8088
Differential Revision: http://reviews.llvm.org/D8086
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231794 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Now that the DataLayout is a mandatory part of the module, let's start
cleaning the codebase. This patch is a first attempt at doing that.
This patch is not exactly NFC as for instance some places were passing
a nullptr instead of the DataLayout, possibly just because there was a
default value on the DataLayout argument to many functions in the API.
Even though it is not purely NFC, there is no change in the
validation.
I turned as many pointer to DataLayout to references, this helped
figuring out all the places where a nullptr could come up.
I had initially a local version of this patch broken into over 30
independant, commits but some later commit were cleaning the API and
touching part of the code modified in the previous commits, so it
seemed cleaner without the intermediate state.
Test Plan:
Reviewers: echristo
Subscribers: llvm-commits
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231740 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
See the two test cases.
; Can fold fcmp with undef on one side by choosing NaN for the undef
; Can fold fcmp with undef on both side
; fcmp u_pred undef, undef -> true
; fcmp o_pred undef, undef -> false
; because whatever you choose for the first undef
; you can choose NaN for the other undef
Reviewers: hfinkel, chandlerc, majnemer
Reviewed By: majnemer
Subscribers: majnemer, llvm-commits
Differential Revision: http://reviews.llvm.org/D7617
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231626 91177308-0d34-0410-b5e6-96231b3b80d8
Multiplication is not dependent on signedness, so just treating
all input ranges as unsigned is not incorrect. However it will cause
overly pessimistic ranges (such as full-set) when used with signed
negative values.
Teach multiply to try to interpret its inputs as both signed and
unsigned, and then to take the most specific (smallest population)
as its result.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231483 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
DataLayout keeps the string used for its creation.
As a side effect it is no longer needed in the Module.
This is "almost" NFC, the string is no longer
canonicalized, you can't rely on two "equals" DataLayout
having the same string returned by getStringRepresentation().
Get rid of DataLayoutPass: the DataLayout is in the Module
The DataLayout is "per-module", let's enforce this by not
duplicating it more than necessary.
One more step toward non-optionality of the DataLayout in the
module.
Make DataLayout Non-Optional in the Module
Module->getDataLayout() will never returns nullptr anymore.
Reviewers: echristo
Subscribers: resistor, llvm-commits, jholewinski
Differential Revision: http://reviews.llvm.org/D7992
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231270 91177308-0d34-0410-b5e6-96231b3b80d8
The intrinsic is no longer generated by the front-end. Remove the intrinsic and
auto-upgrade it to a vector shuffle.
Reviewed by Nadav
This is related to rdar://problem/18742778.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231182 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This does not conceptually belongs here. Instead provide a shortcut
getModule() that provides access to the DataLayout.
Reviewers: chandlerc, echristo
Reviewed By: echristo
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8027
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231147 91177308-0d34-0410-b5e6-96231b3b80d8
I removed the copy ctor, thinking that'd be the end of it - these
iterators should be perfectly assignable even from disjoint ranges (as
any iterator would be) - exkcept that the member was const.
Unconstify it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231146 91177308-0d34-0410-b5e6-96231b3b80d8
There's no reason to disallow assigning an iterator from one range to an
iterator that previously iterated over a disjoint range. This then
follows the Rule of Zero, allowing implicit copy construction to be used
without hitting the case that's deprecated in C++11.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231142 91177308-0d34-0410-b5e6-96231b3b80d8
Accidentally committed a few more of these cleanup changes than
intended. Still breaking these out & tidying them up.
This reverts commit r231135.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231136 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231135 91177308-0d34-0410-b5e6-96231b3b80d8
Ultimately, __CxxFrameHandler3 needs us to put a stack offset in a
table, and it will take responsibility for copying the exception object
into that slot. Modelling the exception object as an SSA value returned
by begincatch isn't going to work in general, so make it use an output
parameter.
Reviewers: andrew.w.kaylor
Differential Revision: http://reviews.llvm.org/D7920
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231086 91177308-0d34-0410-b5e6-96231b3b80d8
Move the specialized metadata nodes for the new debug info hierarchy
into place, finishing off PR22464. I've done bootstraps (and all that)
and I'm confident this commit is NFC as far as DWARF output is
concerned. Let me know if I'm wrong :).
The code changes are fairly mechanical:
- Bumped the "Debug Info Version".
- `DIBuilder` now creates the appropriate subclass of `MDNode`.
- Subclasses of DIDescriptor now expect to hold their "MD"
counterparts (e.g., `DIBasicType` expects `MDBasicType`).
- Deleted a ton of dead code in `AsmWriter.cpp` and `DebugInfo.cpp`
for printing comments.
- Big update to LangRef to describe the nodes in the new hierarchy.
Feel free to make it better.
Testcase changes are enormous. There's an accompanying clang commit on
its way.
If you have out-of-tree debug info testcases, I just broke your build.
- `upgrade-specialized-nodes.sh` is attached to PR22564. I used it to
update all the IR testcases.
- Unfortunately I failed to find way to script the updates to CHECK
lines, so I updated all of these by hand. This was fairly painful,
since the old CHECKs are difficult to reason about. That's one of
the benefits of the new hierarchy.
This work isn't quite finished, BTW. The `DIDescriptor` subclasses are
almost empty wrappers, but not quite: they still have loose casting
checks (see the `RETURN_FROM_RAW()` macro). Once they're completely
gutted, I'll rename the "MD" classes to "DI" and kill the wrappers. I
also expect to make a few schema changes now that it's easier to reason
about everything.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231082 91177308-0d34-0410-b5e6-96231b3b80d8
Add the final bits of API that `DIBuilder` needs before the new nodes
can be moved into place.
- Add `MDType::clone()` and `MDType::setFlags()` to support
`DIBuilder::createTypeWithFlags()`.
- Add `MDBasicType::get()` overload that just requires a tag and a
name, as a convenience for `DIBuilder::createUnspecifiedType()`.
- Add `MDLocalVariable::withInline()` and
`MDLocalVariable::withoutInline()` to support
`llvm::createInlinedVariable()` and
`llvm::cleanseInlinedVariable()`.
(Somehow these got lost inside the "move into place" patch I'm about to
commit -- better to commit separately!)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231079 91177308-0d34-0410-b5e6-96231b3b80d8
Fix `MDScope::getFile()` so that it correctly returns a valid `MDFile`
even when it's an instance of `MDFile`. This logic is necessary because
of r230057. I'm working on moving the new hierarchy into place
out-of-tree (on track to commit Monday morning, BTW), and this was
exposed by a few failing tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230871 91177308-0d34-0410-b5e6-96231b3b80d8
AnalysisResult::getResultImpl reuses an iterator into a DenseMap after
inserting elements into it. This change adds code to recompute the
iterator before the second use.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230718 91177308-0d34-0410-b5e6-96231b3b80d8
Use the IRBuilder helpers for gc.statepoint and gc.result, instead of
coding the construction by hand. Note that the gc.statepoint IRBuilder
handles only CallInst, not InvokeInst; retain that part of hand-coding.
Differential Revision: http://reviews.llvm.org/D7518
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230591 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change fixes the FIXME that you recently added when you committed
(a modified version of) my patch. When `InstCombine` combines a load and
store of an pointer to those of an equivalently-sized integer, it currently
drops any `!nonnull` metadata that might be present. This change replaces
`!nonnull` metadata with `!range !{ 1, -1 }` metadata instead.
Reviewers: chandlerc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7621
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230462 91177308-0d34-0410-b5e6-96231b3b80d8
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
This adds support for the QPX vector instruction set, which is used by the
enhanced A2 cores on the IBM BG/Q supercomputers. QPX vectors are 256 bytes
wide, holding 4 double-precision floating-point values. Boolean values, modeled
here as <4 x i1> are actually also represented as floating-point values
(essentially { -1, 1 } for { false, true }). QPX shares many features with
Altivec and VSX, but is distinct from both of them. One major difference is
that, instead of adding completely-separate vector registers, QPX vector
registers are extensions of the scalar floating-point registers (lane 0 is the
corresponding scalar floating-point value). The operations supported on QPX
vectors mirrors that supported on the scalar floating-point values (with some
additional ones for permutations and logical/comparison operations).
I've been maintaining this support out-of-tree, as part of the bgclang project,
for several years. This is not the entire bgclang patch set, but is most of the
subset that can be cleanly integrated into LLVM proper at this time. Adding
this to the LLVM backend is part of my efforts to rebase bgclang to the current
LLVM trunk, but is independently useful (especially for codes that use LLVM as
a JIT in library form).
The assembler/disassembler test coverage is complete. The CodeGen test coverage
is not, but I've included some tests, and more will be added as follow-up work.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230413 91177308-0d34-0410-b5e6-96231b3b80d8
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
Split debug info 'flags' bitfield over a vector so the current flags can
be iterated over. This API (in combination with r230107) will be used
for assembly support for symbolic constants.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230108 91177308-0d34-0410-b5e6-96231b3b80d8
Add `DIDescriptor::getFlag(StringRef)` and
`DIDescriptor::getFlagString(unsigned)`. The latter only converts exact
matches; I'll add separate API for breaking the flags bitfield up into
parts.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230107 91177308-0d34-0410-b5e6-96231b3b80d8
In the old (well, current) schema, there are two types of file
references: untagged and tagged (the latter references the former).
!0 = !{!"filename", !"/directory"}
!1 = !{!"0x29", !1} ; DW_TAG_file_type [filename] [/directory]
The interface to `DIBuilder` universally takes the tagged version,
described by `DIFile`. However, most `file:` references actually use
the untagged version directly.
In the new hierarchy, I'm merging this into a single node: `MDFile`.
Originally I'd planned to keep the old schema unchanged until after I
moved the new hierarchy into place.
However, it turns out to be trivial to make `MDFile` match both nodes at
the same time.
- Anyone referencing !1 does so through `DIFile`, whose implementation
I need to gut anyway (as I do the rest of the `DIDescriptor`s).
- Anyone referencing !0 just references an `MDNode`, and expects a
node with two `MDString` operands.
This commit achieves that, and updates all the testcases for the parts
of the new hierarchy that used the two-node schema (I've replaced the
untagged nodes with `distinct !{}` to make the diff clear (otherwise the
metadata all gets renumbered); it might be worthwhile to come back and
delete those nodes and renumber the world, not sure).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230057 91177308-0d34-0410-b5e6-96231b3b80d8
This patch introduces a new mechanism that allows IR modules to co-operatively
build pointer sets corresponding to addresses within a given set of
globals. One particular use case for this is to allow a C++ program to
efficiently verify (at each call site) that a vtable pointer is in the set
of valid vtable pointers for the class or its derived classes. One way of
doing this is for a toolchain component to build, for each class, a bit set
that maps to the memory region allocated for the vtables, such that each 1
bit in the bit set maps to a valid vtable for that class, and lay out the
vtables next to each other, to minimize the total size of the bit sets.
The patch introduces a metadata format for representing pointer sets, an
'@llvm.bitset.test' intrinsic and an LTO lowering pass that lays out the globals
and builds the bitsets, and documents the new feature.
Differential Revision: http://reviews.llvm.org/D7288
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230054 91177308-0d34-0410-b5e6-96231b3b80d8
`DILocation` is a lightweight wrapper. Its accessors check for null and
the correct type, and then forward to `MDLocation`.
Extract a couple of macros to do the `dyn_cast_or_null<>` and default
return logic. I'll be using these to minimize error-prone boilerplate
when I move the new hierarchy into place -- since all the other
subclasses of `DIDescriptor` will similarly become lightweight wrappers.
(Note that I hope to obsolete these wrappers fairly quickly, with the
goal of renaming the underlying types (e.g., I'll rename `MDLocation` to
`DILocation` once the name is free).)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229953 91177308-0d34-0410-b5e6-96231b3b80d8
The instructions were being generated on architectures that don't support avx512.
This reverts commit r229837.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229942 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229933 91177308-0d34-0410-b5e6-96231b3b80d8
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
Add `replaceElements()`, `replaceVTableHolder()`, and
`replaceTemplateParams()` to `MDCompositeTypeBase`. Included an
assertion in `replaceElements()` to match the one in
`DICompositeType::replaceArrays()`.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229744 91177308-0d34-0410-b5e6-96231b3b80d8
The scope/context is always the compile unit, which we replace with
`nullptr` anyway (via `getNonCompileUnitScope()`). Drop it explicitly.
I noticed this field was always null while writing testcase upgrade
scripts to transition to the new hierarchy. Seems wasteful to
transition it over if it's already out-of-use.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229740 91177308-0d34-0410-b5e6-96231b3b80d8
`DIImportedEntity::getEntity()` currently returns a `DIScopeRef`, but
the nodes it references aren't always `DIScope`s. In particular, it can
reference global variables.
Introduce `DIDescriptorRef` to avoid the lie.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229733 91177308-0d34-0410-b5e6-96231b3b80d8
Add missing specialized node overloads for `MDNode::clone()` (they were
on most of the node types already, but missing from the others).
`MDNode::clone()` returns `TempMDNode` (`std::unique_ptr<MDNode,...>`),
while `TempMDSubrange::clone()` (for example) returns the more
convenient `TempMDSubrange` (`std::unique_ptr<TempMDSubrange,...>`).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229579 91177308-0d34-0410-b5e6-96231b3b80d8
We didn't properly handle the out-of-bounds case for
ConstantAggregateZero and UndefValue. This would manifest as a crash
when the constant folder was asked to fold a load of a constant global
whose struct type has no operands.
This fixes PR22595.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229352 91177308-0d34-0410-b5e6-96231b3b80d8
The "dereferenceable" attribute cannot be added via .addAttribute(),
since it also expects a size in bytes. AttrBuilder#addAttribute or
AttributeSet#addAttribute is wrapped by classes Function, InvokeInst,
and CallInst. Add corresponding wrappers to
AttrBuilder#addDereferenceableAttr.
Having done this, propagate the dereferenceable attribute via
gc.relocate, adding a test to exercise it. Note that -datalayout is
required during execution over and above -instcombine, because
InstCombine only optionally requires DataLayoutPass.
Differential Revision: http://reviews.llvm.org/D7510
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229265 91177308-0d34-0410-b5e6-96231b3b80d8
Canonicalize access to function attributes to use the simpler API.
getAttributes().getAttribute(AttributeSet::FunctionIndex, Kind)
=> getFnAttribute(Kind)
getAttributes().hasAttribute(AttributeSet::FunctionIndex, Kind)
=> hasFnAttribute(Kind)
Also, add `Function::getFnStackAlignment()`, and canonicalize:
getAttributes().getStackAlignment(AttributeSet::FunctionIndex)
=> getFnStackAlignment()
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229208 91177308-0d34-0410-b5e6-96231b3b80d8
No caller specifies anything different; these parameters are dead code
and probably always have been. The new hierarchy doesn't bother with
the fields at all (see r228607 and r228652).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229037 91177308-0d34-0410-b5e6-96231b3b80d8
Port `DIExpression::Operand` over to `MDExpression::ExprOperand`. The
logic is needed directly in `MDExpression` to support printing in
assembly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229002 91177308-0d34-0410-b5e6-96231b3b80d8
createReplaceableCompositeType() that allows to create non-forward-declared
temporary nodes.
Paired commit with CFE.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228852 91177308-0d34-0410-b5e6-96231b3b80d8
Add new API for converting temporaries that may self-reference.
Self-referencing nodes are not allowed to be uniqued, so sending them
into `replaceWithUniqued()` is dangerous (and this commit adds
assertions that prevent it).
`replaceWithPermanent()` has similar semantics to `get()` followed by
calls to `replaceOperandWith()`. In particular, if there's a
self-reference, it returns a distinct node; otherwise, it returns a
uniqued one. Like `replaceWithUniqued()` and `replaceWithDistinct()`
(well, it calls out to them) it mutates the temporary node in place if
possible, only calling `replaceAllUsesWith()` on a uniquing collision.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228726 91177308-0d34-0410-b5e6-96231b3b80d8
I noticed this fields were never used in r228607, but I neglected to
propagate that into `MDTemplateParameter` until now. This really should
have been done before commit in r228640; sorry for the churn.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228652 91177308-0d34-0410-b5e6-96231b3b80d8
Add specialized debug info metadata nodes that match the `DIDescriptor`
wrappers (used by `DIBuilder`) closely. Assembly and bitcode support to
follow soon (it'll mostly just be obvious), but this sketches in today's
schema. This is the first big commit (well, the only *big* one aside
from the testcase changes that'll come when I move this into place) for
PR22464.
I've marked a bunch of obvious changes as `TODO`s in the source; I plan
to make those changes promptly after this hierarchy is moved underneath
`DIDescriptor`, but for now I'm aiming mostly to match the status quo.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228640 91177308-0d34-0410-b5e6-96231b3b80d8
intermediate representation. This
- increases consistency by using the same granularity everywhere
- allows for pieces < 1 byte
- DW_OP_piece didn't actually allow storing an offset.
Part of PR22495.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228631 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
It's important that our users immediately know what gc.safepoint_poll
is. Also fix the style of the declaration of CreateGCStatepoint, in
preparation for another change that will wrap it.
Reviewers: reames
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7517
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228626 91177308-0d34-0410-b5e6-96231b3b80d8
`DIExpression` deals with `uint64_t`, so it doesn't make sense that
`createExpression()` is created from `int64_t`. Switch to `uint64_t` to
unify them.
I've temporarily left in the `int64_t` version, which forwards to the
`uint64_t` version. I'll delete it once I've updated the callers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228619 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The alias.scope metadata represents sets of things an instruction might
alias with. When generically combining the metadata from two
instructions the result must be the union of the original sets, because
the new instruction might alias with anything any of the original
instructions aliased with.
Reviewers: hfinkel
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7490
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228525 91177308-0d34-0410-b5e6-96231b3b80d8
Gather and Scatter are new introduced intrinsics, comming after recently implemented masked load and store.
This is the first patch for Gather and Scatter intrinsics. It includes only the syntax, parsing and verification.
Gather and Scatter intrinsics allow to perform multiple memory accesses (read/write) in one vector instruction.
The intrinsics are not target specific and will have the following syntax:
Gather:
declare <16 x i32> @llvm.masked.gather.v16i32(<16 x i32*> <vector of ptrs>, i32 <alignment>, <16 x i1> <mask>, <16 x i32> <passthru>)
declare <8 x float> @llvm.masked.gather.v8f32(<8 x float*><vector of ptrs>, i32 <alignment>, <8 x i1> <mask>, <8 x float><passthru>)
Scatter:
declare void @llvm.masked.scatter.v8i32(<8 x i32><vector value to be stored> , <8 x i32*><vector of ptrs> , i32 <alignment>, <8 x i1> <mask>)
declare void @llvm.masked.scatter.v16i32(<16 x i32> <vector value to be stored> , <16 x i32*> <vector of ptrs>, i32 <alignment>, <16 x i1><mask> )
Vector of ptrs - a set of source/destination addresses, to load/store the value.
Mask - switches on/off vector lanes to prevent memory access for switched-off lanes
vector of ptrs, value and mask should have the same vector width.
These are code examples where gather / scatter should be used and will allow function vectorization
;void foo1(int * restrict A, int * restrict B, int * restrict C) {
; for (int i=0; i<SIZE; i++) {
; A[i] = B[C[i]];
; }
;}
;void foo3(int * restrict A, int * restrict B) {
; for (int i=0; i<SIZE; i++) {
; A[B[i]] = i+5;
; }
;}
Tests will come in the following patches, with CodeGen and Vectorizer.
http://reviews.llvm.org/D7433
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228521 91177308-0d34-0410-b5e6-96231b3b80d8
Since testing the function indirectly is tricky, introduce a direct
print-memderefs pass, in the same spirit as print-memdeps, which prints
dereferenceability information matched by FileCheck.
Differential Revision: http://reviews.llvm.org/D7075
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228369 91177308-0d34-0410-b5e6-96231b3b80d8
This pass is responsible for figuring out where to place call safepoints and safepoint polls. It doesn't actually make the relocations explicit; that's the job of the RewriteStatepointsForGC pass (http://reviews.llvm.org/D6975).
Note that this code is not yet finalized. Its moving in tree for incremental development, but further cleanup is needed and will happen over the next few days. It is not yet part of the standard pass order.
Planned changes in the near future:
- I plan on restructuring the statepoint rewrite to use the functions add to the IRBuilder a while back.
- In the current pass, the function "gc.safepoint_poll" is treated specially but is not an intrinsic. I plan to make identifying the poll function a property of the GCStrategy at some point in the near future.
- As follow on patches, I will be separating a collection of test cases we have out of tree and submitting them upstream.
- It's not explicit in the code, but these two patches are introducing a new state for a statepoint which looks a lot like a patchpoint. There's no a transient form which doesn't yet have the relocations explicitly represented, but does prevent reordering of memory operations. Once this is in, I need to update actually make this explicit by reserving the 'unused' argument of the statepoint as a flag, updating the docs, and making the code explicitly check for such a thing. This wasn't really planned, but once I split the two passes - which was done for other reasons - the intermediate state fell out. Just reminds us once again that we need to merge statepoints and patchpoints at some point in the not that distant future.
Future directions planned:
- Identifying more cases where a backedge safepoint isn't required to ensure timely execution of a safepoint poll.
- Tweaking the insertion process to generate easier to optimize IR. (For example, investigating making SplitBackedge) the default.
- Adding opt-in flags for a GCStrategy to use this pass. Once done, add this pass to the actual pass ordering.
Differential Revision: http://reviews.llvm.org/D6981
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228090 91177308-0d34-0410-b5e6-96231b3b80d8
Allow `GenericDebugNode` construction directly from `MDString`, rather
than requiring `StringRef`s. I've refactored the `StringRef`
constructors to use these. There's no real functionality change here,
except for exposing the lower-level API.
The purpose of this is to simplify construction of string operands when
reading bitcode. It's unnecessarily indirect to parse an `MDString` ID,
lookup the `MDString` in the bitcode reader list, get the `StringRef`
out of that, and then have `GenericDebugNode::getImpl()` use
`MDString::get()` to acquire the original `MDString`. Instead, this
allows the bitcode reader to directly pass in the `MDString`.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227848 91177308-0d34-0410-b5e6-96231b3b80d8
Move debug-info-centred `Metadata` subclasses into their own
header/source file. A couple of private template functions are needed
from both `Metadata.cpp` and `DebugInfoMetadata.cpp`, so I've moved them
to `lib/IR/MetadataImpl.h`.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227835 91177308-0d34-0410-b5e6-96231b3b80d8
over declarations.
This is both quite unproductive and causes things to crash, for example
domtree would just assert.
I've added a declaration and a domtree run to the basic high-level tests
for the new pass manager.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227724 91177308-0d34-0410-b5e6-96231b3b80d8
querying of the pass registry.
The pass manager relies on the static registry of PassInfo objects to
perform all manner of its functionality. I don't understand why it does
much of this. My very vague understanding is that this registry is
touched both during static initialization *and* while each pass is being
constructed. As a consequence it is hard to make accessing it not
require a acquiring some lock. This lock ends up in the hot path of
setting up, tearing down, and invaliditing analyses in the legacy pass
manager.
On most systems you can observe this as a non-trivial % of the time
spent in 'ninja check-llvm'. However, I haven't really seen it be more
than 1% in extreme cases of compiling more real-world software,
including LTO.
Unfortunately, some of the GPU JITs are seeing this taking essentially
all of their time because they have very small IR running through
a small pass pipeline very many times (at least, this is the vague
understanding I have of it).
This patch tries to minimize the cost of looking up PassInfo objects by
leveraging the fact that the objects themselves are immutable and they
are allocated separately on the heap and so don't have their address
change. It also requires a change I made the last time I tried to debug
this problem which removed the ability to de-register a pass from the
registry. This patch creates a single access path to these objects
inside the PMTopLevelManager which memoizes the result of querying the
registry. This is somewhat gross as I don't really know if
PMTopLevelManager is the *right* place to put it, and I dislike using
a mutable member to memoize things, but it seems to work.
For long-lived pass managers this should completely eliminate
the cost of acquiring locks to look into the pass registry once the
memoized cache is warm. For 'ninja check' I measured about 1.5%
reduction in CPU time and in total time on a machine with 32 hardware
threads. For normal compilation, I don't know how much this will help,
sadly. We will still pay the cost while we populate the memoized cache.
I don't think it will hurt though, and for LTO or compiles with many
small functions it should still be a win. However, for tight loops
around a pass manager with many passes and small modules, this will help
tremendously. On the AArch64 backend I saw nearly 50% reductions in time
to complete 2000 cycles of spinning up and tearing down the pipeline.
Measurements from Owen of an actual long-lived pass manager show more
along the lines of 10% improvements.
Differential Revision: http://reviews.llvm.org/D7213
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227299 91177308-0d34-0410-b5e6-96231b3b80d8
Essentially DataLayout is global and affects the layout of ABI
level objects. Preferred alignment could change on a per function
basis as we change CPU features.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227118 91177308-0d34-0410-b5e6-96231b3b80d8
This change reverts the interesting parts of 226311 (and 227046). This change introduced two problems, and I've been convinced that an alternate approach is preferrable anyways.
The bugs were:
- Registery appears to require all users be within the same linkage unit. After this change, asking for "statepoint-example" in Transform/ would sometimes get you nullptr, whereas asking the same question in CodeGen would return the right GCStrategy. The correct long term fix is to get rid of the utter hack which is Registry, but I don't have time for that right now. 227046 appears to have been an attempt to fix this, but I don't believe it does so completely.
- GCMetadataPrinter::finishAssembly was being called more than once per GCStrategy. Each Strategy was being added to the GCModuleInfo multiple times.
Once I get time again, I'm going to split GCModuleInfo into the gc.root specific part and a GCStrategy owning Analysis pass. I'm probably also going to kill off the Registry. Once that's done, I'll move the new GCStrategyAnalysis and all built in GCStrategies into Analysis. (As original suggested by Chandler.) This will accomplish my original goal of being able to access GCStrategy from Transform/ without adding all of the builtin GCs to IR/.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227109 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
V8->V9:
- cleanup tests
V7->V8:
- addressed feedback from David:
- switched to range-based 'for' loops
- fixed formatting of tests
V6->V7:
- rebased and adjusted AsmPrinter args
- CamelCased .td, fixed formatting, cleaned up names, removed unused patterns
- diffstat: 3 files changed, 203 insertions(+), 227 deletions(-)
V5->V6:
- addressed feedback from Chandler:
- reinstated full verbose standard banner in all files
- fixed variables that were not in CamelCase
- fixed names of #ifdef in header files
- removed redundant braces in if/else chains with single statements
- fixed comments
- removed trailing empty line
- dropped debug annotations from tests
- diffstat of these changes:
46 files changed, 456 insertions(+), 469 deletions(-)
V4->V5:
- fix setLoadExtAction() interface
- clang-formated all where it made sense
V3->V4:
- added CODE_OWNERS entry for BPF backend
V2->V3:
- fix metadata in tests
V1->V2:
- addressed feedback from Tom and Matt
- removed top level change to configure (now everything via 'experimental-backend')
- reworked error reporting via DiagnosticInfo (similar to R600)
- added few more tests
- added cmake build
- added Triple::bpf
- tested on linux and darwin
V1 cover letter:
---------------------
recently linux gained "universal in-kernel virtual machine" which is called
eBPF or extended BPF. The name comes from "Berkeley Packet Filter", since
new instruction set is based on it.
This patch adds a new backend that emits extended BPF instruction set.
The concept and development are covered by the following articles:
http://lwn.net/Articles/599755/http://lwn.net/Articles/575531/http://lwn.net/Articles/603983/http://lwn.net/Articles/606089/http://lwn.net/Articles/612878/
One of use cases: dtrace/systemtap alternative.
bpf syscall manpage:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b4fc1a460f3017e958e6a8ea560ea0afd91bf6fe
instruction set description and differences vs classic BPF:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/filter.txt
Short summary of instruction set:
- 64-bit registers
R0 - return value from in-kernel function, and exit value for BPF program
R1 - R5 - arguments from BPF program to in-kernel function
R6 - R9 - callee saved registers that in-kernel function will preserve
R10 - read-only frame pointer to access stack
- two-operand instructions like +, -, *, mov, load/store
- implicit prologue/epilogue (invisible stack pointer)
- no floating point, no simd
Short history of extended BPF in kernel:
interpreter in 3.15, x64 JIT in 3.16, arm64 JIT, verifier, bpf syscall in 3.18, more to come in the future.
It's a very small and simple backend.
There is no support for global variables, arbitrary function calls, floating point, varargs,
exceptions, indirect jumps, arbitrary pointer arithmetic, alloca, etc.
From C front-end point of view it's very restricted. It's done on purpose, since kernel
rejects all programs that it cannot prove safe. It rejects programs with loops
and with memory accesses via arbitrary pointers. When kernel accepts the program it is
guaranteed that program will terminate and will not crash the kernel.
This patch implements all 'must have' bits. There are several things on TODO list,
so this is not the end of development.
Most of the code is a boiler plate code, copy-pasted from other backends.
Only odd things are lack or < and <= instructions, specialized load_byte intrinsics
and 'compare and goto' as single instruction.
Current instruction set is fixed, but more instructions can be added in the future.
Signed-off-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Subscribers: majnemer, chandlerc, echristo, joerg, pete, rengolin, kristof.beyls, arsenm, t.p.northover, tstellarAMD, aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D6494
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227008 91177308-0d34-0410-b5e6-96231b3b80d8
These things are potentially used for non-DWARF data (see the discussion
in PR22235), so take the `Dwarf` out of the name. Since the new name
gives fewer clues, update the doxygen to properly describe what they
are.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226874 91177308-0d34-0410-b5e6-96231b3b80d8
During `MDNode::deleteTemporary()`, call `replaceAllUsesWith(nullptr)`
to update all tracking references to `nullptr`.
This fixes PR22280, where inverted destruction order between tracking
references and the temporaries themselves caused a use-after-free in
`LLParser`.
An alternative fix would be to add an assertion that there are no users,
and continue to fix inverted destruction order in clients (like
`LLParser`), but instead I decided to make getting-teardown-right easy.
(If someone disagrees let me know.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226866 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Some parsers need references back to the option they are members of. This is used for handling the argument string as well as by the various pass name parsers for making pass names into flags.
Making parsers that need to refer back to the option have a reference to the option eliminates some of the members of various parsers, and enables further code cleanup.
Reviewers: dexonsmith
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7131
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226864 91177308-0d34-0410-b5e6-96231b3b80d8
Specifically, gc.result benefits from this greatly. Instead of:
gc.result.int.*
gc.result.float.*
gc.result.ptr.*
...
We now have a gc.result.* that can specialize to literally any type.
Differential Revision: http://reviews.llvm.org/D7020
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226857 91177308-0d34-0410-b5e6-96231b3b80d8
This code was confusing, since it created a `DIExpressionIterator` from
an invalid start point (although it wasn't wrong: it never actually
iterated). Now that the underlying iterator has `getNumber()`, just use
it directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226773 91177308-0d34-0410-b5e6-96231b3b80d8
Reduce code duplication between `DIBuilder` and `DIExpressionIterator`
by implementing a `getNumber()` directly in the iterator.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226772 91177308-0d34-0410-b5e6-96231b3b80d8
ConstantArrays constructed during linking can cause quadratic memory
explosion. An example is the ConstantArrays constructed when linking in
GlobalVariables with appending linkage.
Releasing all unused constants can cause a 20% LTO compile-time
slowdown for a large application. So this commit releases unused ConstantArrays
only.
rdar://19040716. It reduces memory footprint from 20+G to 6+G.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226592 91177308-0d34-0410-b5e6-96231b3b80d8
Use `unsigned` instead of `StorageType` for the bitfield to prevent MSVC
from treating the top bit of the bitfield as a sign bit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226570 91177308-0d34-0410-b5e6-96231b3b80d8
Now that the clone methods used by `MapMetadata()` don't do any
remapping (and return a temporary), they make more sense as member
functions on `MDNode` (and subclasses).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226541 91177308-0d34-0410-b5e6-96231b3b80d8
Rather than relying on updating switch statements correctly, detect
whether `setHash()` exists in the subclass. If so, call
`recalculateHash()` and `setHash(0)` appropriately.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226531 91177308-0d34-0410-b5e6-96231b3b80d8
As part of PR22235, introduce `DwarfNode` and `GenericDwarfNode`. The
former is a metadata node with a DWARF tag. The latter matches our
current (generic) schema of a header with string (and stringified
integer) data and an arbitrary number of operands.
This doesn't move it into place yet; that change will require a large
number of testcase updates.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226529 91177308-0d34-0410-b5e6-96231b3b80d8
Swap usage of `SubclassData32` and `MDNodeSubclassData`, and rename
`MDNodeSubclassData` to `NumUnresolved`. Small drive-by cleanup to
`countUnresolvedOperands()` since otherwise the name clash with local
vars named `NumUnresolved` would be confusing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226523 91177308-0d34-0410-b5e6-96231b3b80d8
As pointed out in r226501, the distinction between `MDNode` and
`UniquableMDNode` is confusing. When we need subclasses of `MDNode`
that don't use all its functionality it might make sense to break it
apart again, but until then this makes the code clearer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226520 91177308-0d34-0410-b5e6-96231b3b80d8
Take advantage of the new ability of temporary nodes to mutate to
distinct and uniqued nodes to greatly simplify the `MapMetadata()`
helper functions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226511 91177308-0d34-0410-b5e6-96231b3b80d8
Add `MDNode::replaceWithUniqued()` and `MDNode::replaceWithDistinct()`,
which mutate temporary nodes to become uniqued or distinct. On uniquing
collisions, the unique version is returned and the node is deleted.
This takes advantage of temporary nodes being folded back in, and should
let me clean up some awkward logic in `MapMetadata()`.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226510 91177308-0d34-0410-b5e6-96231b3b80d8
r226504 added `TempMDNodeDeleter` to help with `std::unique_ptr<>`-izing
the `MDNode::getTemporary()` interface. It doesn't need to be
templated, though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226509 91177308-0d34-0410-b5e6-96231b3b80d8
Change `MDTuple::getTemporary()` and `MDLocation::getTemporary()` to
return (effectively) `std::unique_ptr<T, MDNode::deleteTemporary>`, and
clean up call sites. (For now, `DIBuilder` call sites just call
`release()` immediately.)
There's an accompanying change in each of clang and polly to use the new
API.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226504 91177308-0d34-0410-b5e6-96231b3b80d8
Remove `MDNodeFwdDecl` (as promised in r226481). Aside from API
changes, there's no real functionality change here.
`MDNode::getTemporary()` now forwards to `MDTuple::getTemporary()`,
which returns a tuple with `isTemporary()` equal to true.
The main point is that we can now add temporaries of other `MDNode`
subclasses, needed for PR22235 (I introduced `MDNodeFwdDecl` in the
first place because I didn't recognize this need, and thought they were
only needed to handle forward references).
A few things left out of (or highlighted by) this commit:
- I've had to remove the (few) uses of `std::unique_ptr<>` to deal
with temporaries, since the destructor is no longer public.
`getTemporary()` should probably return the equivalent of
`std::unique_ptr<T, MDNode::deleteTemporary>`.
- `MDLocation::getTemporary()` doesn't exist yet (worse, it actually
does exist, but does the wrong thing: `MDNode::getTemporary()` is
inherited and returns an `MDTuple`).
- `MDNode` now only has one subclass, `UniquableMDNode`, and the
distinction between them is actually somewhat confusing.
I'll fix those up next.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226501 91177308-0d34-0410-b5e6-96231b3b80d8
Merge `getDistinct()`'s implementation with those of `get()` and
`getIfExists()` for both `MDTuple` and `MDLocation`. This will make it
easier to scale to supporting temporaries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226497 91177308-0d34-0410-b5e6-96231b3b80d8
Unify the definitions of `MDNode::isResolved()` and
`UniquableMDNode::isResolved()`. Previously, `UniquableMDNode` could
answer this question more efficiently, but now that RAUW support has
been unified with `MDNodeFwdDecl`, `MDNode` doesn't need any casts to
figure out the answer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226485 91177308-0d34-0410-b5e6-96231b3b80d8
Add an `LLVMContext &` to `ReplaceableMetadataImpl`, create a class that
either holds a reference to an `LLVMContext` or owns a
`ReplaceableMetadataImpl`, and use the new class in `MDNode`.
- This saves a pointer in `UniquableMDNode` at the cost of a pointer
in `ValueAsMetadata` (which didn't used to store the `LLVMContext`).
There are far more of the former.
- Unifies RAUW support between `MDNodeFwdDecl` (which is going away,
see r226481) and `UniquableMDNode`.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226484 91177308-0d34-0410-b5e6-96231b3b80d8
Change `MDNode::isDistinct()` to only apply to 'distinct' nodes (not
temporaries), and introduce `MDNode::isUniqued()` and
`MDNode::isTemporary()` for the other two possibilities.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226482 91177308-0d34-0410-b5e6-96231b3b80d8
More clearly describe the type of storage used for `Metadata`.
- `Uniqued`: uniqued, stored in the context.
- `Distinct`: distinct, stored in the context.
- `Temporary`: not owned by anyone.
This is the first in a series of commits to fix a design problem with
`MDNodeFwdDecl` that I need to solve for PR22235. While `MDNodeFwdDecl`
works well as a forward declaration, we use `MDNode::getTemporary()` for
more than forward declarations -- we also need to create early versions
of nodes (with fields not filled in) that we'll fill out later (see
`DIBuilder::finalize()` and `CGDebugInfo::finalize()` for examples).
This was a blind spot I had when I introduced `MDNodeFwdDecl` (which
David Blaikie (indirectly) highlighted in an unrelated review [1]).
[1]: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150112/252381.html
In general, we need `MDTuple::getTemporary()` to give a temporary tuple
(like `MDNodeFwdDecl`), `MDLocation::getTemporary()` to give a temporary
location, and (the problem at hand) `GenericDebugMDNode::getTemporary()`
to give a temporary generic debug node.
So I need to fold the idea of "temporary" nodes back into
`UniquableMDNode`. (More commits to follow as I refactor.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226481 91177308-0d34-0410-b5e6-96231b3b80d8
frontends to use a DIExpression with a DW_OP_deref instead.
This is not only a much more natural place for this informationl; there
is also a technical reason: The FlagIndirectVariable is used to mark a
variable that is turned into a reference by virtue of the calling
convention; this happens for example to aggregate return values.
The inliner, for example, may actually need to undo this indirection to
correctly represent the value in its new context. This is impossible to
implement because the DIVariable can't be safely modified. We can however
safely construct a new DIExpression on the fly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226476 91177308-0d34-0410-b5e6-96231b3b80d8
Note: This change ended up being slightly more controversial than expected. Chandler has tentatively okayed this for the moment, but I may be revisiting this in the near future after we settle some high level questions.
Rather than have the GCStrategy object owned by the GCModuleInfo - which is an immutable analysis pass used mainly by gc.root - have it be owned by the LLVMContext. This simplifies the ownership logic (i.e. can you have two instances of the same strategy at once?), but more importantly, allows us to access the GCStrategy in the middle end optimizer. To this end, I add an accessor through Function which becomes the canonical way to get at a GCStrategy instance.
In the near future, this will allows me to move some of the checks from http://reviews.llvm.org/D6808 into the Verifier itself, and to introduce optimization legality predicates for some of the recent additions to InstCombine. (These will follow as separate changes.)
Differential Revision: http://reviews.llvm.org/D6811
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226311 91177308-0d34-0410-b5e6-96231b3b80d8
Similar to the unaligned cases.
Test was generated with update_llc_test_checks.py.
Part of <rdar://problem/17688758>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226296 91177308-0d34-0410-b5e6-96231b3b80d8
The transform is somewhat involved, but the basic idea is simple: find
derived pointers that have been offset from the base pointer using gep
and replace the relocate of the derived pointer with a gep to the
relocated base pointer (with the same offset).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226060 91177308-0d34-0410-b5e6-96231b3b80d8
This commit moves `MDLocation`, finishing off PR21433. There's an
accompanying clang commit for frontend testcases. I'll attach the
testcase upgrade script I used to PR21433 to help out-of-tree
frontends/backends.
This changes the schema for `DebugLoc` and `DILocation` from:
!{i32 3, i32 7, !7, !8}
to:
!MDLocation(line: 3, column: 7, scope: !7, inlinedAt: !8)
Note that empty fields (line/column: 0 and inlinedAt: null) don't get
printed by the assembly writer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226048 91177308-0d34-0410-b5e6-96231b3b80d8
Sometimes teardown happens before the debug info graph is complete
(e.g., when clang throws an error). In that case, `MDNode`s will still
have RAUW, so deleting constants that the `MDNode`s point at will be
relatively expensive -- it'll cause re-uniquing all up the chain (what
I've been referring to as "teardown madness").
So, drop references *before* deleting constants. We need to drop a few
more references now: the metadata side of the metadata/value bridges
needs to be dropped off the cliff along with the rest of it (previously,
the bridges were cleaned before we did anything with the `MDNode`s).
There's no real functionality change here -- state before and after
`LLVMContextImpl::~LLVMContextImpl()` is unchanged -- so no testcase.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226044 91177308-0d34-0410-b5e6-96231b3b80d8
utils/sort_includes.py.
I clearly haven't done this in a while, so more changed than usual. This
even uncovered a missing include from the InstrProf library that I've
added. No functionality changed here, just mechanical cleanup of the
include order.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225974 91177308-0d34-0410-b5e6-96231b3b80d8
This adds the domtree analysis to the new pass manager. The analysis
returns the same DominatorTree result entity used by the old pass
manager and essentially all of the code is shared. We just have
different boilerplate for running and printing the analysis.
I've converted one test to run in both modes just to make sure this is
exercised while both are live in the tree.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225969 91177308-0d34-0410-b5e6-96231b3b80d8
into the new pass manager's analysis cache which stores results
by-value.
Technically speaking, the dom trees were originally not movable but
copyable! This, unsurprisingly, didn't work at all -- the copy was
shallow and just resulted in rampant memory corruption. This change
explicitly forbids copying (as it would need to be a deep copy) and
makes them explicitly movable with the unsurprising boiler plate to
member-wise move them because we can't rely on MSVC to generate this
code for us. =/
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225966 91177308-0d34-0410-b5e6-96231b3b80d8
and expose the necessary hooks in the API directly.
This makes it much cleaner for example to log the usage of a pass
manager from a library. It also makes it more obvious that this
functionality isn't "optional" or "asserts-only" for the pass manager.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225841 91177308-0d34-0410-b5e6-96231b3b80d8
referring to and give them nice comments.
Previously, these were used, but now things use the generic form of the
AnalysisManager.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225833 91177308-0d34-0410-b5e6-96231b3b80d8
Add a new subclass of `UniquableMDNode`, `MDLocation`. This will be the
IR version of `DebugLoc` and `DILocation`. The goal is to rename this
to `DILocation` once the IR classes supersede the `DI`-prefixed
wrappers.
This isn't used anywhere yet. Part of PR21433.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225824 91177308-0d34-0410-b5e6-96231b3b80d8
a nested class template for the PassModel, and use the T-suffix for the
two typedefs to match the code in the AnalysisManager.
This is the last of the fairly fundamental code cleanups here. Will be
focusing on the printing of analyses next to finish that aspect off.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225785 91177308-0d34-0410-b5e6-96231b3b80d8
of templates in the new pass manager.
The analysis manager is now itself just a template predicated on the IR
unit. This makes lots of the templates really trivial and more clear:
they are all parameterized on a single type, the IR unit's type.
Everything else is a function of that. To me, this is a really nice
cleanup of the APIs and removes a layer of 'magic' and 'indirection'
that really wasn't there and just got in the way of understanding what
is going on here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225784 91177308-0d34-0410-b5e6-96231b3b80d8
the generic functionality of the pass managers themselves.
In the new infrastructure, the pass "manager" isn't actually interesting
at all. It just pipelines a single chunk of IR through N passes. We
don't need to know anything about the IR or the passes to do this really
and we can replace the 3 implementations of the exact same functionality
with a single generic PassManager template, complementing the single
generic AnalysisManager template.
I've left typedefs in place to give convenient names to the various
obvious instantiations of the template.
With this, I think I've nuked almost all of the redundant logic in the
managers, and I think the overall design is actually simpler for having
single templates that clearly indicate there is no special logic here.
The logging is made somewhat more annoying by this change, but I don't
think the difference is worth having heavy-weight traits to help log
things.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225783 91177308-0d34-0410-b5e6-96231b3b80d8
The functions {pred,succ,use,user}_{begin,end} exist, but many users
have to check *_begin() with *_end() by hand to determine if the
BasicBlock or User is empty. Fix this with a standard *_empty(),
demonstrating a few usecases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225760 91177308-0d34-0410-b5e6-96231b3b80d8
template.
This consolidates three copies of nearly the same core logic. It adds
"complexity" to the ModuleAnalysisManager in that it makes it possible
to share a ModuleAnalysisManager across multiple modules... But it does
so by deleting *all of the code*, so I'm OK with that. This will
naturally make fixing bugs in this code much simpler, etc.
The only down side here is that we have to use 'typename' and 'this->'
in various places, and the implementation is lifted into the header.
I'll take that for the code size reduction.
The convenient names are still typedef-ed and used throughout so that
users can largely ignore this aspect of the implementation.
The follow-up change to this will do the exact same refactoring for the
PassManagers. =D
It turns out that the interesting different code is almost entirely in
the adaptors. At the end, that should be essentially all that is left.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225757 91177308-0d34-0410-b5e6-96231b3b80d8
This name is less descriptive, but it sort of puts things in the
'llvm.frame...' namespace, relating it to frameallocate and
frameaddress. It also avoids using "allocate" and "allocation" together.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225752 91177308-0d34-0410-b5e6-96231b3b80d8
These intrinsics allow multiple functions to share a single stack
allocation from one function's call frame. The function with the
allocation may only perform one allocation, and it must be in the entry
block.
Functions accessing the allocation call llvm.recoverframeallocation with
the function whose frame they are accessing and a frame pointer from an
active call frame of that function.
These intrinsics are very difficult to inline correctly, so the
intention is that they be introduced rarely, or at least very late
during EH preparation.
Reviewers: echristo, andrew.w.kaylor
Differential Revision: http://reviews.llvm.org/D6493
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225746 91177308-0d34-0410-b5e6-96231b3b80d8
so has clang-format. Notably, this fixes a bunch of formatting in the
CGSCC pass manager side of things that has been improved in clang-format
recently.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225743 91177308-0d34-0410-b5e6-96231b3b80d8
templated interface.
So far, every single IR unit I can come up with has address-identity.
That is, when two units of IR are both active in LLVM, their addresses
will be distinct of the IR is distinct. This is clearly true for
Modules, Functions, BasicBlocks, and Instructions. It turns out that the
only practical way to make the CGSCC stuff work the way we want is to
make it true for SCCs as well. I expect this pattern to continue.
When first designing the pass manager code, I kept this dimension of
freedom in the type parameters, essentially allowing for a wrapper-type
whose address did not form identity. But that really no longer makes
sense and is making the code more complex or subtle for no gain. If we
ever have an actual use case for this, we can figure out what makes
sense then and there. It will be better because then we will have the
actual example in hand.
While the simplifications afforded in this patch are fairly small
(mostly sinking the '&' out of many type parameters onto a few
interfaces), it would have become much more pronounced with subsequent
changes. I have a sequence of changes that will completely remove the
code duplication that currently exists between all of the pass managers
and analysis managers. =] Should make things much cleaner and avoid bug
fixing N times for the N pass managers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225723 91177308-0d34-0410-b5e6-96231b3b80d8
Add generic dispatch for the parts of `UniquableMDNode` that cast to
`MDTuple`. This makes adding other subclasses (like PR21433's
`MDLocation`) easier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225697 91177308-0d34-0410-b5e6-96231b3b80d8
Stop erasing `MDNode`s from the uniquing sets in `LLVMContextImpl`
during teardown (in particular, during
`UniquableMDNode::~UniquableMDNode()`). Although it's currently
feasible, there isn't any clear benefit and it may not be feasible for
other subclasses (which don't explicitly store the lookup hash).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225696 91177308-0d34-0410-b5e6-96231b3b80d8
Same as with `MDTuple`, factor out a `friend MDNode` by moving creation
logic to the concrete subclass.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225690 91177308-0d34-0410-b5e6-96231b3b80d8
Move creation logic for `MDTuple`s down where it belongs. Once there
are a few more subclasses, these functions really won't make much sense
here (the `friend` relationship was already awkward). For now, leave
the `MDNode` versions around, but have it forward down.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225685 91177308-0d34-0410-b5e6-96231b3b80d8
Split `GenericMDNode` into two classes (with more descriptive names).
- `UniquableMDNode` will be a common subclass for `MDNode`s that are
sometimes uniqued like constants, and sometimes 'distinct'.
This class gets the (short-lived) RAUW support and related API.
- `MDTuple` is the basic tuple that has always been returned by
`MDNode::get()`. This is as opposed to more specific nodes to be
added soon, which have additional fields, custom assembly syntax,
and extra semantics.
This class gets the hash-related logic, since other sublcasses of
`UniquableMDNode` may need to hash based on other fields.
To keep this diff from getting too big, I've added casts to `MDTuple`
that won't really scale as new subclasses of `UniquableMDNode` are
added, but I'll clean those up incrementally.
(No functionality change intended.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225682 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of returning early on `handleChangedOperand()` recursion
(finally identified (and test added) in r225657), prevent it upfront by
releasing operands before RAUW.
Aside from massively different program flow, there should be no
functionality change ;).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225665 91177308-0d34-0410-b5e6-96231b3b80d8
Change the return of `MDNode::isDistinct()` for `MDNode::getTemporary()`
to `true`. They aren't uniqued.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225646 91177308-0d34-0410-b5e6-96231b3b80d8
The bitcode reading interface used std::error_code to report an error to the
callers and it is the callers job to print diagnostics.
This is not ideal for error handling or diagnostic reporting:
* For error handling, all that the callers care about is 3 possibilities:
* It worked
* The bitcode file is corrupted/invalid.
* The file is not bitcode at all.
* For diagnostic, it is user friendly to include far more information
about the invalid case so the user can find out what is wrong with the
bitcode file. This comes up, for example, when a developer introduces a
bug while extending the format.
The compromise we had was to have a lot of error codes.
With this patch we use the DiagnosticHandler to communicate with the
human and std::error_code to communicate with the caller.
This allows us to have far fewer error codes and adds the infrastructure to
print better diagnostics. This is so because the diagnostics are printed when
he issue is found. The code that detected the problem in alive in the stack and
can pass down as much context as needed. As an example the patch updates
test/Bitcode/invalid.ll.
Using a DiagnosticHandler also moves the fatal/non-fatal error decision to the
caller. A simple one like llvm-dis can just use fatal errors. The gold plugin
needs a bit more complex treatment because of being passed non-bitcode files. An
hypothetical interactive tool would make all bitcode errors non-fatal.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225562 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
One more attempt to fix UBSan reports: make sure DenseMapInfo::getEmptyKey()
and DenseMapInfo::getTombstoneKey() doesn't do any upcasts/downcasts to/from Value*.
Test Plan: check-llvm test suite with/without UBSan bootstrap
Reviewers: chandlerc, dexonsmith
Subscribers: llvm-commits, majnemer
Differential Revision: http://reviews.llvm.org/D6903
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225558 91177308-0d34-0410-b5e6-96231b3b80d8
This was used previously for metadata but is no longer needed there. Not
doing this simplifies ValueHandle and will make it easier to fix things
like AssertingVH's DenseMapInfo.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225487 91177308-0d34-0410-b5e6-96231b3b80d8
Allow distinct `MDNode`s to be explicitly created. There's no way (yet)
of representing their distinctness in assembly/bitcode, however, so this
still isn't first-class.
Part of PR22111.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225406 91177308-0d34-0410-b5e6-96231b3b80d8
Add API to indicate whether an `MDNode` is distinct. A distinct node is
not stored in the MDNode uniquing tables, and will never be returned by
`MDNode::get()`.
Although distinct nodes are only currently created by uniquing
collisions (when operands change), PR22111 will allow these nodes to be
explicitly created.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225401 91177308-0d34-0410-b5e6-96231b3b80d8
`MDNode::replaceOperandWith()` changes all instances of metadata. Stop
using it when linking module flags, since (due to uniquing) the flag
values could be used by other metadata.
Instead, use new API `NamedMDNode::setOperand()` to update the reference
directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225397 91177308-0d34-0410-b5e6-96231b3b80d8
requiring and invalidating specific analyses. Also make their printed
names match their class names. Writing these out as prose really doesn't
make sense to me any more.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225346 91177308-0d34-0410-b5e6-96231b3b80d8
We can't drop support for RAUW entirely in `MDNode`s, since it's
required for graph construction. This comment was from before I'd done
the math on that (out-of-tree), and never should have been committed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225334 91177308-0d34-0410-b5e6-96231b3b80d8
passes too many time.
I think this is actually the issue that someone raised with me at the
developer's meeting and in an email, but that we never really got to the
bottom of. Having all the testing utilities made it much easier to dig
down and uncover the core issue.
When a pass manager is running many passes over a single function, we
need it to invalidate the analyses between each run so that they can be
re-computed as needed. We also need to track the intersection of
preserved higher-level analyses across all the passes that we run (for
example, if there is one module analysis which all the function analyses
preserve, we want to track that and propagate it). Unfortunately, this
interacted poorly with any enclosing pass adaptor between two IR units.
It would see the intersection of preserved analyses, and need to
invalidate any other analyses, but some of the un-preserved analyses
might have already been invalidated *and recomputed*! We would fail to
propagate the fact that the analysis had already been invalidated.
The solution to this struck me as really strange at first, but the more
I thought about it, the more natural it seemed. After a nice discussion
with Duncan about it on IRC, it seemed even nicer. The idea is that
invalidating an analysis *causes* it to be preserved! Preserving the
lack of result is trivial. If it is recomputed, great. Until something
*else* invalidates it again, we're good.
The consequence of this is that the invalidate methods on the analysis
manager which operate over many passes now consume their
PreservedAnalyses object, update it to "preserve" every analysis pass to
which it delivers an invalidation (regardless of whether the pass
chooses to be removed, or handles the invalidation itself by updating
itself). Then we return this augmented set from the invalidate routine,
letting the pass manager take the result and use the intersection of
*that* across each pass run to compute the final preserved set. This
accounts for all the places where the early invalidation of an analysis
has already "preserved" it for a future run.
I've beefed up the testing and adjusted the assertions to show that we
no longer repeatedly invalidate or compute the analyses across nested
pass managers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225333 91177308-0d34-0410-b5e6-96231b3b80d8
Use this to test that path of invalidation. This test actually shows
redundant invalidation here that is really bad. I'm going to work on
fixing that next, but wanted to commit the test harness now that its all
working.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225257 91177308-0d34-0410-b5e6-96231b3b80d8
a specific analysis result.
This is quite handy to test things, and will also likely be very useful
for debugging issues. You could narrow down pass validation failures by
walking these invalidate pass runs up and down the pass pipeline, etc.
I've added support to the pass pipeline parsing to be able to create one
of these for any analysis pass desired.
Just adding this class uncovered one latent bug where the
AnalysisManager CRTP base class had a hard-coded Module type rather than
using IRUnitT.
I've also added tests for invalidation and caching of analyses in
a basic way across all the pass managers. These in turn uncovered two
more bugs where we failed to correctly invalidate an analysis -- its
results were invalidated but the key for re-running the pass was never
cleared and so it was never re-run. Quite nasty. I'm very glad to debug
this here rather than with a full system.
Also, yes, the naming here is horrid. I'm going to update some of the
names to be slightly less awful shortly. But really, I've no "good"
ideas for naming. I'll be satisfied if I can get it to "not bad".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225246 91177308-0d34-0410-b5e6-96231b3b80d8
is a no-op other than requiring some analysis results be available.
This can be used in real pass pipelines to force the usually lazy
analysis running to eagerly compute something at a specific point, and
it can be used to test the pass manager infrastructure (my primary use
at the moment).
I've also added bit of pipeline parsing magic to support generating
these directly from the opt command so that you can directly use these
when debugging your analysis. The syntax is:
require<analysis-name>
This can be used at any level of the pass manager. For example:
cgscc(function(require<my-analysis>,no-op-function))
This would produce a no-op function pass requiring my-analysis, followed
by a fully no-op function pass, both of these in a function pass manager
which is nested inside of a bottom-up CGSCC pass manager which is in the
top-level (implicit) module pass manager.
I have zero attachment to the particular syntax I'm using here. Consider
it a straw man for use while I'm testing and fleshing things out.
Suggestions for better syntax welcome, and I'll update everything based
on any consensus that develops.
I've used this new functionality to more directly test the analysis
printing rather than relying on the cgscc pass manager running an
analysis for me. This is still minimally tested because I need to have
analyses to run first! ;] That patch is next, but wanted to keep this
one separate for easier review and discussion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225236 91177308-0d34-0410-b5e6-96231b3b80d8
when all are being preserved.
We want to short-circuit this for a couple of reasons. One, I don't
really want passes to grow a dependency on actually receiving their
invalidate call when they've been preserved. I'm thinking about removing
this entirely. But more importantly, preserving everything is likely to
be the common case in a lot of scenarios, and it would be really good to
bypass all of the invalidation and preservation machinery there.
Avoiding calling N opaque functions to try to invalidate things that are
by definition still valid seems important. =]
This wasn't really inpsired by much other than seeing the spam in the
logging for analyses, but it seems better ot get it checked in rather
than forgetting about it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225163 91177308-0d34-0410-b5e6-96231b3b80d8
manager.
This starts to allow us to test analyses more easily, but it's really
only the beginning. Some of the code here is still untestable without
manual changes to create analysis passes, but I wanted to factor it into
a small of chunks as possible.
Next up in order to be able to test things are, in no particular order:
- No-op analyses passes so we don't have to use real ones to exercise
the pass maneger itself.
- Automatic way of generating dummy passes that require an analysis be
run, including a variant that calls a 'print' method on a pass to make
it even easier to print out the results of an analysis.
- Dummy passes that invalidate all analyses for their IR unit so we can
test invalidation and re-runs.
- Automatic way to print each analysis pass as it is re-run.
- Automatic but optional verification of analysis passes everywhere
possible.
I'm not claiming I'll get to all of these immediately, but that's what
is in the pipeline at some stage. I'm fleshing out exactly what I need
and what to prioritize by working on converting analyses and then trying
to test the conversion. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225162 91177308-0d34-0410-b5e6-96231b3b80d8
units.
This was debated back and forth a bunch, but using references is now
clearly cleaner. Of all the code written using pointers thus far, in
only one place did it really make more sense to have a pointer. In most
cases, this just removes immediate dereferencing from the code. I think
it is much better to get errors on null IR units earlier, potentially
at compile time, than to delay it.
Most notably, the legacy pass manager uses references for its routines
and so as more and more code works with both, the use of pointers was
likely to become really annoying. I noticed this when I ported the
domtree analysis over and wrote the entire thing with references only to
have it fail to compile. =/ It seemed better to switch now than to
delay. We can, of course, revisit this is we learn that references are
really problematic in the API.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225145 91177308-0d34-0410-b5e6-96231b3b80d8
FunctionPassManager. These never got documented, likely due to the
clutter of this header file. This fixes another problem people noticed
when they started trying to use the new pass manager.
I've also used this to document the aspirational constraints I would
like to hold passes to. I don't really have a better place to document
such things at this point, but eventually will probably create a proper
.rst file and page for the LLVM pass infrastructure that carries such
high-level concerns.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225097 91177308-0d34-0410-b5e6-96231b3b80d8
concept-based polymorphism in the pass manager to a separate header.
I got feedback from someone reading the code and trying to use it that
this was really making it hard to dive in and start using these APIs and
that makes a lot of sense.
This only requires a moderate amount of gymnastics to separate in this
way, namely rinsing the PreservedAnalysis object through a template
argument in a few places so that it is dependent and we only examine it
on instantiation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225094 91177308-0d34-0410-b5e6-96231b3b80d8
Nothing particularly interesting, just adding infrastructure for use by in tree users and out of tree users.
Note: These were extracted out of a working frontend, but they have not been well tested in isolation.
Differential Revision: http://reviews.llvm.org/D6807
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224981 91177308-0d34-0410-b5e6-96231b3b80d8
This change implements four basic optimizations:
If a relocated value isn't used, it doesn't need to be relocated.
If the value being relocated is null, relocation doesn't change that. (Technically, this might be collector specific. I don't know of one which it doesn't work for though.)
If the value being relocated is undef, the relocation is meaningless.
If the value being relocated was known nonnull, the relocated pointer also isn't null. (Since it points to the same source language object.)
I outlined other planned work in comments.
Differential Revision: http://reviews.llvm.org/D6600
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224968 91177308-0d34-0410-b5e6-96231b3b80d8
a size and alignment. Several assertions in DwarfDebug rely on all variable
types to report back a size, or to be derived from a type with a size.
Tested in CFE.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224780 91177308-0d34-0410-b5e6-96231b3b80d8
In resent times asan and valgrind have found way more memory management bugs
in llvm than the special purpose leak detector.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224703 91177308-0d34-0410-b5e6-96231b3b80d8
(X & INT_MIN) ? X & INT_MAX : X into X & INT_MAX
(X & INT_MIN) ? X : X & INT_MAX into X
(X & INT_MIN) ? X | INT_MIN : X into X
(X & INT_MIN) ? X : X | INT_MIN into X | INT_MIN
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224669 91177308-0d34-0410-b5e6-96231b3b80d8
Make `DICompositeType` mutators private to prevent misuse. All calls to
`setArrays()` and `setContainingType()` should go through
`DIBuilder::replaceArrays()` and `DIBuilder::replaceVTableHolder()`.
This is a follow-up to r224482 (now that clang has been updated in
r224483).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224486 91177308-0d34-0410-b5e6-96231b3b80d8
Add API to DIBuilder to handle self-referencing `DICompositeType`s.
Self-references aren't expected in the debug info graph, and we take
advantage of that by only calling `resolveCycles()` on nodes that were
once forward declarations (otherwise, DIBuilder needs an expensive
tracking reference to every unresolved node it creates, which in cyclic
graphs is *all of them*).
However, clang seems to create self-referencing `DICompositeType`s. Add
API to manage this safely. The paired commit to clang will include the
regression test.
I'll make the `DICompositeType` API `private` in a follow-up to prevent
misuse (I've separated that to prevent build failures from missing the
clang commit).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224482 91177308-0d34-0410-b5e6-96231b3b80d8
Also remove redundant documentation:
- doxygen will copy documentation to overriden methods.
- Use \copydoc on PIMPL classes instead of replicating the text.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224089 91177308-0d34-0410-b5e6-96231b3b80d8
`MDString`s can have arbitrary characters in them. Prevent an assertion
that fired in `BitcodeWriter` because of sign extension by copying the
characters into the record as `unsigned char`s.
Based on a patch by Keno Fischer; fixes PR21882.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224077 91177308-0d34-0410-b5e6-96231b3b80d8
This gives us better leak detection messages, like `Value` has.
This also has the side effect of papering over a problem where
`MachineInstr`s are added as garbage to the leak detector and then
deleted without being removed. If `MDNode::getTemporary()` allocates an
`MDNodeFwdDecl` in the same spot, the leak detector asserts. By
separating `MDNode`s into their own container we lose that assertion.
Since `MachineInstr` is required to have a trivial destructor, its usage
of `LeakDetector` at all is pretty suspect. I'll be sending a patch
soon to strip that out.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224060 91177308-0d34-0410-b5e6-96231b3b80d8
Rather than requiring overloads in the wrapper and the impl, just
overload the impl and use templates in the wrapper. This makes it less
error prone to add more overloads (`void *` defeats any chance the
compiler has at noticing bugs, so the easier the better).
At the same time, correct the comment that was lying about not changing
functionality for `Value`.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224058 91177308-0d34-0410-b5e6-96231b3b80d8
