| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
| |
X shifted by undef results in undef because the undef value can
represent values greater than the width of the operands.
llvm-svn: 223968
|
| |
|
|
| |
llvm-svn: 223967
|
| |
|
|
|
|
|
|
| |
These methods are only used by MCJIT and are very specific to it. In fact, they
are also fairly specific to the fact that we have a dynamic linker of
relocatable objects.
llvm-svn: 223964
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the large code model we have to first get the address of the GOT entry, load
the address of the constant, and then load the constant itself.
To avoid these loads and the GOT entry alltogether this commit changes the way
how FP constants are materialized in the large code model. The constats are now
materialized in a GPR and then bitconverted/moved into the FPR.
Reviewed by Tim Northover
Fixes rdar://problem/16572564.
llvm-svn: 223941
|
| |
|
|
| |
llvm-svn: 223940
|
| |
|
|
| |
llvm-svn: 223933
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Add patterns to match SSE (shufpd) and AVX (vpermilpd) shuffle codegen
when storing the high element of a v2f64. The existing patterns were
only checking for an unpckh type of shuffle.
http://llvm.org/bugs/show_bug.cgi?id=21791
Differential Revision: http://reviews.llvm.org/D6586
llvm-svn: 223929
|
| |
|
|
| |
llvm-svn: 223926
|
| |
|
|
|
|
| |
Dividing by zero yields an undefined value.
llvm-svn: 223924
|
| |
|
|
|
|
|
| |
Exact shifts always keep the non-zero bits of their input. This means
it keeps it's undef bits.
llvm-svn: 223923
|
| |
|
|
|
|
|
|
|
|
|
| |
expects
EltsFromConsecutiveLoads was apparently only ever called for 128-bit vectors, and assumed this implicitly. r223518 started calling it for AVX-sized vectors, causing the code path that had this assumption to crash.
This adds a check to make this path fire only for 128-bit vectors.
Differential Revision: http://reviews.llvm.org/D6579
llvm-svn: 223922
|
| |
|
|
|
|
| |
We already optimized rem %X, 0 to undef, we should do the same for div.
llvm-svn: 223919
|
| |
|
|
| |
llvm-svn: 223911
|
| |
|
|
|
|
|
| |
Since Value objects can't have null bytes in their name, we shouldn't
allow them in the labels of basic blocks.
llvm-svn: 223907
|
| |
|
|
|
|
|
| |
Don't call `dropAllReferences()` from `MDNode::~MDNode()`, call it
directly from `~MDNodeFwdDecl()` and `~GenericMDNode()`.
llvm-svn: 223904
|
| |
|
|
| |
llvm-svn: 223903
|
| |
|
|
|
|
|
|
| |
As indicated by the tests, it is possible to feed the AsmParser an
invalid datalayout string. We should verify the result of parsing this
string regardless of whether or not we have assertions enabled.
llvm-svn: 223898
|
| |
|
|
|
|
|
|
| |
We can't mark partially undefined registers, so we have to allow reading
a register in the machine verifier if just parts of a register are
defined.
llvm-svn: 223896
|
| |
|
|
|
|
|
|
| |
In the subregister liveness tracking case we do not create implicit
reads on partial register writes anymore, still we need to produce a new
SSA value for partial writes so the live segment has to end.
llvm-svn: 223895
|
| |
|
|
| |
llvm-svn: 223894
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
tracking.
Adding the implicit defs/uses to the superregisters is semantically questionable
but was not dangerous before as the register allocator never assigned the same
register to two overlapping LiveIntervals even when the actually live
subregisters do not overlap. With subregister liveness tracking enabled this
does actually happen and leads to subsequent bugs if we don't stop adding
the superregister defs/uses.
llvm-svn: 223892
|
| |
|
|
| |
llvm-svn: 223891
|
| |
|
|
|
|
| |
This allows it to add subregister ranges into the union.
llvm-svn: 223890
|
| |
|
|
| |
llvm-svn: 223888
|
| |
|
|
| |
llvm-svn: 223887
|
| |
|
|
| |
llvm-svn: 223886
|
| |
|
|
| |
llvm-svn: 223884
|
| |
|
|
| |
llvm-svn: 223883
|
| |
|
|
| |
llvm-svn: 223882
|
| |
|
|
| |
llvm-svn: 223881
|
| |
|
|
| |
llvm-svn: 223880
|
| |
|
|
| |
llvm-svn: 223878
|
| |
|
|
|
|
| |
This code adds the required data structures. Algorithms to compute it follow.
llvm-svn: 223877
|
| |
|
|
| |
llvm-svn: 223876
|
| |
|
|
|
|
|
| |
We don't allow Value* to have names which contain null bytes. The
AsmParser should reject .ll files that try to do this.
llvm-svn: 223869
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to only combine intrinsics, and turn them into VLD1_UPD/VST1_UPD
when the base pointer is incremented after the load/store.
We can do the same thing for generic load/stores.
Note that we can only combine the first load/store+adds pair in
a sequence (as might be generated for a v16f32 load for instance),
because other combines turn the base pointer addition chain (each
computing the address of the next load, from the address of the last
load) into independent additions (common base pointer + this load's
offset).
Differential Revision: http://reviews.llvm.org/D6585
llvm-svn: 223862
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the current implementation, GCStrategy is a part of the ownership structure for the gc metadata which describes a Module. It also contains a reference to the module in question. As a result, GCStrategy instances are essentially Module specific.
I plan to transition away from this design. Instead, a GCStrategy will be owned by the LLVMContext. It will be a lightweight policy object which contains no information about the Modules or Functions involved, but can be easily reached given a Function.
The first step in this transition is to remove the direct Module reference from GCStrategy. This also requires removing the single user of this reference, the GCMetadataPrinter hierarchy. In theory, this will allow the lifetime of the printers to be scoped to the LLVMContext as well, but in practice, I'm not actually changing that. (Yet?)
An alternate design would have been to move the direct Module reference into the GCMetadataPrinter and change the keying of the owning maps to explicitly key off both GCStrategy and Module. I'm open to doing it that way instead, but didn't see much value in preserving the per Module association for GCMetadataPrinters.
The next change in this sequence will be to start unwinding the intertwined ownership between GCStrategy, GCModuleInfo, and GCFunctionInfo.
Differential Revision: http://reviews.llvm.org/D6566
llvm-svn: 223859
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were two major problems with `MDNode` memory management.
1. `MDNode::operator new()` called a placement array constructor for
`MDOperand`. What? Each operand needs to be placed individually.
2. `MDNode::operator delete()` failed to destruct the `MDOperand`s at
all.
Frankly it's hard to understand how this worked locally, how this
survived an LTO bootstrap, or how it worked on most of the bots.
llvm-svn: 223858
|
| |
|
|
| |
llvm-svn: 223856
|
| |
|
|
|
|
| |
potential confusion with the std::map type.
llvm-svn: 223853
|
| |
|
|
|
|
|
|
|
|
| |
Speculatively handle a recursion in
`GenericMDNode::handleChangedOperand()`. I'm hoping this fixes the
failing hexagon bot [1].
[1]: http://lab.llvm.org:8011/builders/llvm-hexagon-elf/builds/13434
llvm-svn: 223849
|
| |
|
|
|
|
|
| |
Tested by adding assert(LoopVectorPreHeader == VecPreheader) on LLVM
test suite and SPECs.
llvm-svn: 223847
|
| |
|
|
| |
llvm-svn: 223845
|
| |
|
|
|
|
|
|
|
| |
Move the combiner-state check into another function, add a few
small comments, and use a more general type in a cast<>.
In preparation for a future patch.
llvm-svn: 223834
|
| |
|
|
|
|
|
| |
And flip its final condition.
In preparation for a future patch.
llvm-svn: 223833
|
| |
|
|
|
|
|
|
|
| |
It was missing from the VLD1/VST1 handling logic, even though the
corresponding instructions exist (same form as v2i64).
In preparation for a future patch.
llvm-svn: 223832
|
| |
|
|
|
|
|
|
|
|
|
| |
RAUW in a deterministic order to try to recover the hexagon bot [1],
whose tests started failing once my GCC fixes were in for r223802.
Otherwise, I'm not sure why tests would fail there and not here.
[1]: http://lab.llvm.org:8011/builders/llvm-hexagon-elf/builds/13426
llvm-svn: 223829
|
| |
|
|
|
|
| |
This is the same return type of Archive::create.
llvm-svn: 223827
|
| |
|
|
|
|
|
|
|
|
|
| |
LLVM_EXPLICIT is only supported by recent version of MSVC, and it seems
the not-so-recent versions get confused about the operator bool() when
tryint to resolve operator== calls.
This removed the operator bool()'s since they don't seem to be used
anyway.
llvm-svn: 223824
|
| |
|
|
| |
llvm-svn: 223823
|