| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 212454
|
| |
|
|
| |
llvm-svn: 212449
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
essentially a DAG combine that never gets a chance to run.
We might typically expect DAG combining to remove shuffles-of-splats and
other similar patterns, but we don't get a chance to run the DAG
combiner when we recursively form sub-shuffles during the lowering of
a shuffle. So instead hand-roll a really important combine directly into
the lowering code to detect shuffles-of-splats, especially shuffles of
an all-zero splat which needn't even have the same element width, etc.
This lets the new vector shuffle lowering handle shuffles which
implement things like zero-extension really nicely. This will become
even more important when I wire the legalization of zero-extension to
vector shuffles with the new widening legalization strategy.
llvm-svn: 212444
|
| |
|
|
|
|
|
|
|
|
|
| |
We've been performing the wrong operation on ARM for "atomicrmw nand" for
years, since "a NAND b" is "~(a & b)" rather than ARM's very tempting "a & ~b".
This bled over into the generic expansion pass.
So I assume no-one has ever actually tried to do an atomic nand in the real
world. Oh well.
llvm-svn: 212443
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This completes the handling for DLL import storage symbols when lowering
instructions. A DLL import storage symbol must have an additional load
performed prior to use. This is applicable to variables and functions.
This is particularly important for non-function symbols as it is possible to
handle function references by emitting a thunk which performs the translation
from the unprefixed __imp_ symbol to the proper symbol (although, this is a
non-optimal lowering). For a variable symbol, no such thunk can be
accommodated.
llvm-svn: 212431
|
| |
|
|
|
|
|
|
| |
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>).
llvm-svn: 212430
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 212429
|
| |
|
|
|
|
| |
The value of constant operands will be truncated to fit element width.
llvm-svn: 212428
|
| |
|
|
| |
llvm-svn: 212424
|
| |
|
|
| |
llvm-svn: 212423
|
| |
|
|
| |
llvm-svn: 212420
|
| |
|
|
| |
llvm-svn: 212405
|
| |
|
|
| |
llvm-svn: 212402
|
| |
|
|
| |
llvm-svn: 212401
|
| |
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 212398
|
| |
|
|
| |
llvm-svn: 212380
|
| |
|
|
| |
llvm-svn: 212379
|
| |
|
|
| |
llvm-svn: 212371
|
| |
|
|
|
|
|
| |
This just lets us dump a const MCSymbolData object, no functionality
changed.
llvm-svn: 212365
|
| |
|
|
| |
llvm-svn: 212364
|
| |
|
|
|
|
|
| |
No functionality changed, just make it so that the code _could_ be
uncommented.
llvm-svn: 212363
|
| |
|
|
|
|
| |
Switch a normal for-loop to a range-based for. No functionality changed.
llvm-svn: 212362
|
| |
|
|
| |
llvm-svn: 212361
|
| |
|
|
|
|
|
|
|
| |
A GEP of a non-weak global variable will not be equivalent to another
non-weak global variable or a GEP of such a variable.
Differential Revision: http://reviews.llvm.org/D4238
llvm-svn: 212360
|
| |
|
|
|
|
|
|
|
| |
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).
llvm-svn: 212357
|
| |
|
|
|
|
|
|
|
| |
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.
llvm-svn: 212356
|
| |
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 212354
|
| |
|
|
|
|
| |
This fixes http://llvm.org/PR20202
llvm-svn: 212352
|
| |
|
|
|
|
|
| |
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.
llvm-svn: 212351
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 212350
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 212349
|
| |
|
|
| |
llvm-svn: 212348
|
| |
|
|
| |
llvm-svn: 212347
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D4386
llvm-svn: 212346
|
| |
|
|
| |
llvm-svn: 212344
|
| |
|
|
| |
llvm-svn: 212342
|
| |
|
|
| |
llvm-svn: 212341
|
| |
|
|
|
|
| |
If needed, an ErrorOr should be used.
llvm-svn: 212340
|
| |
|
|
|
|
|
|
|
|
|
|
| |
the value the initializer is referring to.
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.
llvm-svn: 212337
|
| |
|
|
|
|
|
|
|
|
| |
The linker relies on relocation type info (e.g. is it a branch?) to perform the
correct actions, so we should keep that even when we end up using a scattered
relocation for whatever reason.
rdar://problem/17553104
llvm-svn: 212333
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were two issues here:
1. At the very least, scattered relocations cannot use the same code to
determine the corresponding symbol being referred to. For some reason we
pretend there is no symbol, even when one actually exists in the symtab, so to
match this behaviour getRelocationSymbol should simply return symbols_end for
scattered relocations.
2. Printing "-" when we can't get a symbol (including the scattered case, but
not exclusively), isn't that helpful. In both cases there *is* interesting
information in that field, so we should print it. As hex will do.
Small part of rdar://problem/17553104
llvm-svn: 212332
|
| |
|
|
|
|
|
|
| |
can prove that it cannot overflow.
PR20194
llvm-svn: 212331
|
| |
|
|
|
|
|
|
| |
We have detected a documentation bug in the encoding tables of the released
MIPS64r6 specification that has resulted in the wrong encodings being used for
these instructions in LLVM. This commit corrects them.
llvm-svn: 212330
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
any constant, constant FP, or undef splat and to tolerate any undef
lanes in a splat, then replace all uses of isSplatVector in X86's
lowering with it.
This fixes issues where undef lanes in an otherwise splat vector would
prevent the splat logic from firing. It is a touch more awkward to use
this interface, but it is much more accurate. Suggestions for better
interface structuring welcome.
With this fix, the code generated with the widening legalization
strategy for widen_cast-4.ll is *dramatically* improved as the special
lowering strategies for a v16i8 SRA kick in even though the high lanes
are undef.
We also get a slightly different choice for broadcasting an aligned
memory location, and use vpshufd instead of vbroadcastss. This looks
like a minor win for pipelining and domain crossing, but a minor loss
for the number of micro-ops. I suspect its a wash, but folks can easily
tweak the lowering if they want.
llvm-svn: 212324
|
| |
|
|
|
|
|
|
|
|
|
| |
Silvermont can only decode one instruction per cycle if the instruction exceeds 8 bytes.
Also in Silvermont instructions with more than 3 prefixes will cause 3 cycle penalty.
Maximum nop length is limited to 7 bytes when used for padding on Silvermont.
For other x86 processors max nop length remains unchanged 15 bytes.
Differential Revision: http://reviews.llvm.org/D4374
llvm-svn: 212321
|
| |
|
|
|
|
|
|
| |
Summary: This was causing the prologue_end to be incorrectly positioned.
Differential Revision: http://reviews.llvm.org/D4122
llvm-svn: 212318
|
| |
|
|
| |
llvm-svn: 212310
|
| |
|
|
|
|
|
|
|
|
| |
subtarget. This involved having the movt predicate take the current
function - since we care about size in instruction selection for
whether or not to use movw/movt take the function so we can check
the attributes. This required adding the current MachineFunction to
FastISel and propagating through.
llvm-svn: 212309
|
| |
|
|
|
|
|
|
|
| |
We want to encourage users of the C++ LTO API to reuse memory buffers instead
of repeatedly opening and reading the same file contents.
This reverts commit r212305 and implements a tidier scheme.
llvm-svn: 212308
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When INT_MIN is the numerator in a sdiv, we would not properly handle
overflow when calculating the bounds of possible values; abs(INT_MIN) is
not a meaningful number.
Instead, check and handle INT_MIN by reasoning that the largest value is
INT_MIN/-2 and the smallest value is INT_MIN.
This fixes PR20199.
llvm-svn: 212307
|