| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
| |
This compiles with no changes to clang/lld/lldb with MSVC and includes
overloads to various functions which are used by those projects and llvm
which have OwningPtr's as parameters. This should allow out of tree
projects some time to move. There are also no changes to libs/Target,
which should help out of tree targets have time to move, if necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203083 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
selfhost.
The 'Core.h' C-API header is part of the IR LLVM library. (One might
even argue it should be called IR.h, but that's a separate point.) We
can't include it into a Support header without violating the layering,
and in a way that breaks modules. MemoryBuffer's opaque C type was being
defined in the Core.h C-API header despite being in the Support library,
and thus we ended up with this weird issue.
It turns out that there were other constructs from the Support library
in the Core.h header. This patch lifts all of them into Support.h and
then includes that into Core.h.
The only possible fallout is if someone was including Support.h and
relying on Core.h to be visible for their own uses. Considering the
narrow interface actually provided by the C-API for the Support library,
this seems a very, very unlikely mistake.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203071 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
implementation already lived.
After this commit, the only IR-library headers in include/llvm/* are
ones related to the legacy pass infrastructure that I'm planning to
leave there until the new one is farther along.
The only other headers at the top level are linking and initialization
aids that aren't really libraries but just headers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203069 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203066 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
consistent with every other sub-library header in LLVM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203065 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
obviously coupled to the IR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203064 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
make it true.
It ought to be possible to make this truly random access if anyone cares enough.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203060 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
Chandler in review.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203058 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
The iterator is a little complex because we don't want to expose the implementation
details (TrackingVH) of the operand vector to clients.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203053 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
already lives.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203046 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
already lives.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203038 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
| |
are operations that do not access memory but may be sensitive
to floating-point environment changes. LLVM does not attempt
to model FP environment changes, so this was unnecessarily conservative
and was getting on the way of some optimizations, in particular
SLP vectorization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203037 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before llvm-mc would print it, but llc was assuming that it would produce
another section changing directive before one was needed. That assumption is
false with inline asm.
Fixes PR19049.
Another option would be to always create the section, but in the asm printer
avoid printing sections changes during initialization. That would work, but
* We do use the fact that llvm-mc prints it in testing. The tests can be changed
if needed.
* A quick poll on IRC suggest that most developers prefer the implicit .text to
be printed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203001 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
| |
The build was failing with:
error C2664: 'std::atomic_int::atomic_int(const std::atomic_int &)' : cannot convert argument 1 from 'int' to 'const std::atomic_int &'
Apparently "std::atomic_int x(0)" doesn't work, but "std::atomic<int> x(0)"
does.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202988 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202985 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
A version of RefCountedBase that uses std::atomic_int to store its
reference count.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202984 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
implementation already lives.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202961 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
| |
already lived there and it is where it belongs -- this is the in-memory
debug location representation.
This is just cleanup -- Modules can actually cope with this, but that
doesn't make it right. After chatting with folks that have out-of-tree
stuff, going ahead and moving the rest of the headers seems preferable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202960 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
This will allow external callers of these functions to switch over time
rather than forcing a breaking change all a once. These particular
functions were determined by building clang/lld/lldb.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202959 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
to ensure we don't mess up any of the overrides. Necessary for cleaning
up the Value use iterators and enabling range-based traversing of use
lists.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202958 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202957 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202953 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
This will make the transition to unique_ptr easier by allowing more
incremental changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202949 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202946 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202945 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202939 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202937 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
Patch by Manuel Jacob.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202936 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
selection dag (PR19012)
In X86SelectionDagInfo::EmitTargetCodeForMemcpy we check with MachineFrameInfo
to make sure that ESI isn't used as a base pointer register before we choose to
emit rep movs (which clobbers esi).
The problem is that MachineFrameInfo wouldn't know about dynamic allocas or
inline asm that clobbers the stack pointer until SelectionDAGBuilder has
encountered them.
This patch fixes the problem by checking for such things when building the
FunctionLoweringInfo.
Differential Revision: http://llvm-reviews.chandlerc.com/D2954
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202930 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
Patch by Manuel Jacob!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202928 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
itself and teach it to convert between the non-const and const variants.
De-templatetize its usage in APIs to just use the const variant which
always works for those use cases. Also, rename its implementation to
reflect that it is an iterator over *users* not over *uses*.
This is a step toward providing both iterator and range support for
walking the *uses* distinct from the *users*. In a subsequent patch this
will get renamed to make it clear that this is an adaptor over the
fundamental use iterator.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202923 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
I did not intend to cast a pointer to ulittle32_t there because the return
type is const void*.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202916 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
Looks like llvm-readobj is the only customer of this code, and apparently
there's no test to cover this function. I'll write it after finishing
plumbing from llvm-objdump to there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202915 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202902 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202895 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202883 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
| |
source file had already been moved. Also move the unittest into the IR
unittest library.
This may seem an odd thing to put in the IR library but we only really
use this with instructions and it needs the LLVM context to work, so it
is intrinsically tied to the IR library.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202842 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202840 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
PassInfo structures of the legacy pass manager. Also give it the Legacy
prefix as it is not a particularly widely used header.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202839 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
| |
a bit surprising, as the class is almost entirely abstracted away from
any particular IR, however it encodes the comparsion predicates which
mutate ranges as ICmp predicate codes. This is reasonable as they're
used for both instructions and constants. Thus, it belongs in the IR
library with instructions and constants.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202838 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
necessary, but is no longer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202836 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
hardcoded to use IR BasicBlocks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202835 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202834 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
reference the ConstantExpr implementation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202833 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
this would have been required because of the use of DataLayout, but that
has moved into the IR proper. It is still required because this folder
uses the constant folding in the analysis library (which uses the
datalayout) as the more aggressive basis of its folder.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202832 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
IR types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202827 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
one in the tree (or in Polly) is using this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202825 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
| |
directly care about the Value class (it is templated so that the key can
be any arbitrary Value subclass), it is in fact concretely tied to the
Value class through the ValueHandle's CallbackVH interface which relies
on the key type being some Value subclass to establish the value handle
chain.
Ironically, the unittest is already in the right library.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202824 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
| |
Move the test for this class into the IR unittests as well.
This uncovers that ValueMap too is in the IR library. Ironically, the
unittest for ValueMap is useless in the Support library (honestly, so
was the ValueHandle test) and so it already lives in the IR unittests.
Mmmm, tasty layering.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202821 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
obviously is coupled to the IR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202818 91177308-0d34-0410-b5e6-96231b3b80d8
|