Previously, the assertions in PointerIntPair would try to calculate the value
(1 << NumLowBitsAvailable); the inferred type here is 'int', so if there were
more than 31 bits available we'd get a shift overflow.

Also, add a rudimentary unit test file for PointerIntPair.

llvm-svn: 203273

Simplify the remaining ones a bit.

llvm-svn: 203249

No functionality change.

llvm-svn: 203242

This is a preliminary setup change to support a renaming of Windows target
triples.  Split the object file format information out of the environment into a
separate entity.  Unfortunately, file format was previously treated as an
environment with an unknown OS.  This is most obvious in the ARM subtarget where
the handling for macho on an arbitrary platform switches to AAPCS rather than
APCS (as per Apple's needs).

llvm-svn: 203160

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.

llvm-svn: 203083

consistent with every other sub-library header in LLVM.

llvm-svn: 203065

already lives.

llvm-svn: 203046

already lives.

llvm-svn: 203038

When using a //net/ path, we were transforming the trailing / into a '.'
when the path was just the root path and we were iterating backwards.
Forwards iteration and other kinds of root path (C:\, /) were already
correct.

llvm-svn: 202999

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.

llvm-svn: 202959

llvm-svn: 202957

This will make the transition to unique_ptr easier by allowing more
incremental changes.

llvm-svn: 202949

now. ;] Tested on both a static and shared CMake build. Hopefully the
bots will agree.

llvm-svn: 202844

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.

llvm-svn: 202842

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.

llvm-svn: 202838

instructions.

llvm-svn: 202834

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.

llvm-svn: 202824

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.

llvm-svn: 202821

obviously is coupled to the IR.

llvm-svn: 202818

business.

This header includes Function and BasicBlock and directly uses the
interfaces of both classes. It has to do with the IR, it even has that
in the name. =] Put it in the library it belongs to.

This is one step toward making LLVM's Support library survive a C++
modules bootstrap.

llvm-svn: 202814

llvm-svn: 202811

llvm-svn: 202806

The interaction between defaulted operators and move elision isn't
totally obvious, add a unit test so it doesn't break unintentionally.

llvm-svn: 202662

access to it on all host toolchains.

llvm-svn: 202642

Remove the old functions.

llvm-svn: 202636

llvm-svn: 202621

directly, and remove the macro.

llvm-svn: 202612

std::unique_ptr<T>.

Patch by Ahmed Charles!

llvm-svn: 202609

it interoperate (minimally) with std::unique_ptr<T>. This is part of my
plan to migrate LLVM to use std::unique_ptr with a minimal impact on
out-of-tree code.

Patch by Ahmed Charles with some minor cleanups (and bool casts) by me.

llvm-svn: 202608

llvm-svn: 202587

llvm-svn: 202583

llvm-svn: 202510

This lets us run the unittest from the command line without setting
LD_LIBRARY_PATH.

llvm-svn: 202509

llvm-svn: 202286

Prevent a crash in the SmallDenseMap copy constructor whenever the other
map is not in small mode.

<rdar://problem/14292693>

llvm-svn: 202206

No tool does this currently, but as everything else in a module we should be
able to change its DataLayout.

Most of the fix is in DataLayout to make sure it can be reset properly.

The test uses Module::setDataLayout since the fact that we mutate a DataLayout
is an implementation detail. The module could hold a OwningPtr<DataLayout> and
the DataLayout itself could be immutable.

Thanks to Philip Reames for pushing me in the right direction.

llvm-svn: 202198

Instead, have a DataLayoutPass that holds one. This will allow parts of LLVM
don't don't handle passes to also use DataLayout.

llvm-svn: 202168

llvm-svn: 202127

See
<rdar://16149106> [MCJIT] provide a platform-independent way to communicate callee-save frame info.
<rdar://16149279> [MCJIT] get the host OS version from a runtime check, not a configure-time check.

llvm-svn: 202082

After this I will set the default back to F_None. The advantage is that
before this patch forgetting to set F_Binary would corrupt a file on windows.
Forgetting to set F_Text produces one that cannot be read in notepad, which
is a better failure mode :-)

llvm-svn: 202052