Add support for tracking DLLImport storage class information on a per symbol
basis in the ARM instruction selection. Use that information to correctly
mangle the symbol (dllimport symbols are referenced via *__imp_<name>).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212430 91177308-0d34-0410-b5e6-96231b3b80d8
Ensure that all paths that retrieve the symbol name go through GetARMGVSymbol
rather than getSymbol. This is desirable so that any global symbol mangling can
be centralised to this function. The motivation for this is handling of symbols
that are marked as having dll import dll storage. Such a symbol requires an
extra load that is currently handled in the backend and a __imp_ prefix on the
symbol name.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212429 91177308-0d34-0410-b5e6-96231b3b80d8
Use 0 for the invalid buffer instead of -1/~0 and switch to unsigned
representation to enable more idiomatic usage.
Also introduce a trivial SourceMgr::getMainFileID() instead of hard-coding 0/1
to identify the main file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212398 91177308-0d34-0410-b5e6-96231b3b80d8
A number of the ARM intrinsics are aliased with alternative names in MSVC
compatibility mode. This change indicates those intrinsics to permit tablegen
to construct an appropriate list of MSBuiltins. With the corresponding change
in clang, these intrinsics can then be mapped from the frontend.
The tests to validate the intrinsics are aliased correctly will be added with
the corresponding clang change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212377 91177308-0d34-0410-b5e6-96231b3b80d8
The slice(N, M) interface is powerful but not concise when wanting to
drop a few elements off of an ArrayRef, fix this by adding a drop_back
method.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212370 91177308-0d34-0410-b5e6-96231b3b80d8
This better aligns with other LLVM-specific and C++ standard library smart
pointer types.
In particular there are at least a few uses of intrusive refcounting in the
frontend where it's worth investigating std::shared_ptr as a more appropriate
alternative.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212366 91177308-0d34-0410-b5e6-96231b3b80d8
The regular end of the bitcode parsing is in the BitstreamEntry::EndBlock
case.
Should fix the LTO bootstrap on OS X (this function is only used by ld64).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212357 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r212342.
We can get a StringRef into the current Record, but not one in the bitcode
itself since the string is compressed in it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212356 91177308-0d34-0410-b5e6-96231b3b80d8
These are the llvm.* globals and functions.
I don't think it is possible to test this directly since llvm-lto is not
a full linker and will not report duplicated symbols, but this fixes
bootstrap with gold and lto enabled.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212354 91177308-0d34-0410-b5e6-96231b3b80d8
It is not clear if llvm.global_ctors should or should not be in llvm.metadata,
but in practice it is not and we need to ignore it for LTO.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212351 91177308-0d34-0410-b5e6-96231b3b80d8
Add MSBuiltin which is similar in vein to GCCBuiltin. This allows for adding
intrinsics for Microsoft compatibility to individual instructions. This is
needed to permit the creation of ARM specific MSVC extensions.
This is not currently in use, and requires an associated change in clang to
enable use of the intrinsics defined by this new class. This merely sets the
LLVM portion of the infrastructure in place to permit the use of this
functionality. A separate set of changes will enable the new intrinsics.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212350 91177308-0d34-0410-b5e6-96231b3b80d8
IRObjectFile provides all the logic for producing mangled names and getting
symbols from inline assembly.
LTOModule then adds logic for linking specific tasks, like constructing
llvm.compiler_user or extracting linker options from the bitcode.
The rule of the thumb is that IRObjectFile has the functionality that is
needed by both LTO and llvm-ar.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212349 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The tests in this directory are intended to test a single IR instruction
with as few dependencies on other instructions as possible. The aim is to
be very confident that each LLVM-IR instruction is implemented correctly and
with the optimal sequence of instructions, as well as to make it easy to tell
what is tested, and make it easier to bring up new ISA revisions in the
future. This gives us a good foundation on which to test bigger things.
These particular tests will allow testing that MIPS32r6/MIPS64r6 generate
the correct return instruction for returns, calls, and indirect branches.
This will be a bit tricky since the assembly text is identical but the
instruction is actually different. On MIPS32r6/MIPS64r6 'jr $rs' has been
removed in favour of the equivalent 'jalr $zero, $rs'. 'jr $rs' remains as
an alias for 'jalr $zero, $rs'.
Differential Revision: http://reviews.llvm.org/D4266
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212345 91177308-0d34-0410-b5e6-96231b3b80d8
This is useful for functions that are not actually available externally but
referenced by a vtable of some kind. Clang emits functions like this for the MS
ABI.
PR20182.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212337 91177308-0d34-0410-b5e6-96231b3b80d8
