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
Use `isUniqued()` instead of `isStoredDistinctInContext()`, and remove
an assertion that won't be valid once temporaries are merged back in.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226491 91177308-0d34-0410-b5e6-96231b3b80d8
Add an assertion in `UniquableMDNode::resolve()` to prevent temporaries
from being resolved (once they're merged back in). Needed to shuffle
order of `resolve()` and `storeDistinctInContext()` to prevent it from
firing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226489 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
An assignment will produce a symbol with a given section and offset. There is
no way to represent something like "1 byte after a common symbol".
This matches the behavior of GNU as.
Part of PR22217.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226470 91177308-0d34-0410-b5e6-96231b3b80d8
No change in this commit, but clang was changed to also produce trivial comdats when
needed.
Original message:
Don't create new comdats in CodeGen.
This patch stops the implicit creation of comdats during codegen.
Clang now sets the comdat explicitly when it is required. With this patch clang and gcc
now produce the same result in pr19848.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226467 91177308-0d34-0410-b5e6-96231b3b80d8
and updated.
This may appear to remove handling for things like alias analysis when
splitting critical edges here, but in fact no callers of SplitEdge
relied on this. Similarly, all of them wanted to preserve LCSSA if there
was any update of the loop info. That makes the interface much simpler.
With this, all of BasicBlockUtils.h is free of Pass arguments and
prepared for the new pass manager. This is tho majority of utilities
that relied on pass arguments.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226459 91177308-0d34-0410-b5e6-96231b3b80d8
while refactoring this API for the new pass manager.
No functionality changed here, the code didn't actually support this
option.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226457 91177308-0d34-0410-b5e6-96231b3b80d8
APIs and replace it and numerous booleans with an option struct.
The critical edge splitting API has a really large surface of flags and
so it seems worth burning a small option struct / builder. This struct
can be constructed with the various preserved analyses and then flags
can be flipped in a builder style.
The various users are now responsible for directly passing along their
analysis information. This should be enough for the critical edge
splitting to work cleanly with the new pass manager as well.
This API is still pretty crufty and could be cleaned up a lot, but I've
focused on this change just threading an option struct rather than
a pass through the API.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226456 91177308-0d34-0410-b5e6-96231b3b80d8
test. Do that after we suppress the warnings for unknown pragmas as this
warning flag is quite new in Clang and so old Clang's would warn all the
time on this file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226444 91177308-0d34-0410-b5e6-96231b3b80d8
we can while splitting critical edges.
The only code which called this and didn't require simplified loops to
be preserved is polly, and the code behaves correctly there anyways.
Without this change, it becomes really hard to share this code with the
new pass manager where things like preserving loop simplify form don't
make any sense.
If anyone discovers this code behaving incorrectly, what it *should* be
testing for is whether the loops it needs to be in simplified form are
in fact in that form. It should always be trying to preserve that form
when it exists.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226443 91177308-0d34-0410-b5e6-96231b3b80d8
In case of blocks with many memory-accessing instructions, alias checking can take lot of time
(because calculating the memory dependencies has quadratic complexity).
I chose a limit which resulted in no changes when running the benchmarks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226439 91177308-0d34-0410-b5e6-96231b3b80d8
We don't need to exclude patchpoints from the implicit r2 dependence in
FastISel because it is added as an implicit operand and, thus, should not
confuse that StackMap code.
By inspection / no test case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226434 91177308-0d34-0410-b5e6-96231b3b80d8
Our PPC64 ELF V2 call lowering logic added r2 as an operand to all direct call
instructions in order to represent the dependency on the TOC base pointer
value. Restricting this to ELF V2, however, does not seem to make sense: calls
under ELF V1 have the same dependence, and indirect calls have an r2 dependence
just as direct ones. Make sure the dependence is noted for all calls under both
ELF V1 and ELF V2.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226432 91177308-0d34-0410-b5e6-96231b3b80d8
SplitLandingPadPredecessors and remove the Pass argument from its
interface.
Another step to the utilities being usable with both old and new pass
managers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226426 91177308-0d34-0410-b5e6-96231b3b80d8
There is no reason for this state to be exposed as public. The single element
constructor was superfulous in light of the single element ArrayRef
constructor.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226424 91177308-0d34-0410-b5e6-96231b3b80d8
Since MCStreamer isn't part of Support, the dtor can't be called from
here - so just pass by reference instead. This is rather imperfect, but
will hopefully suffice.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226415 91177308-0d34-0410-b5e6-96231b3b80d8
