| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
This iterator iterates over subregister and their associated subregister indices
at the same time.
llvm-svn: 223893
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Now we can relate lanemasks in a virtual register to register units.
llvm-svn: 223889
|
| |
|
|
| |
llvm-svn: 223888
|
| |
|
|
| |
llvm-svn: 223887
|
| |
|
|
| |
llvm-svn: 223886
|
| |
|
|
| |
llvm-svn: 223885
|
| |
|
|
| |
llvm-svn: 223884
|
| |
|
|
| |
llvm-svn: 223883
|
| |
|
|
| |
llvm-svn: 223882
|
| |
|
|
| |
llvm-svn: 223881
|
| |
|
|
| |
llvm-svn: 223880
|
| |
|
|
| |
llvm-svn: 223879
|
| |
|
|
| |
llvm-svn: 223878
|
| |
|
|
|
|
| |
This code adds the required data structures. Algorithms to compute it follow.
llvm-svn: 223877
|
| |
|
|
| |
llvm-svn: 223876
|
| |
|
|
| |
llvm-svn: 223875
|
| |
|
|
|
|
|
| |
This works like the composeSubRegisterIndices() function but transforms
a subregister lane mask instead of a subregister index.
llvm-svn: 223874
|
| |
|
|
|
|
|
|
| |
Let tablegen compute the combination of subregister lanemasks for all
subregisters in a register/register class. This is preparation for further
work subregister allocation
llvm-svn: 223873
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Nothing particularly interesting here, just documenting the way the code currently works before I start changing it...
llvm-svn: 223866
|
| |
|
|
| |
llvm-svn: 223864
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The complicated situation is when we have to keep an alias but drop a GV
that is part of the aliasee.
We used to clone the dropped GV and make the clone internal. This is wasteful
as we know the original will be dropped.
With this patch what is done instead is set the linkage of the original to
internal and replace all uses (but the one in the alias) with a new
declaration that takes the name of the old GV. This saves us from having
to copy the body.
llvm-svn: 223863
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 223857
|
| |
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 223841
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
It is a static method of IRObjectFile, so having to use
IRObjectFile::createIRObjectFile was redundant.
llvm-svn: 223822
|
| |
|
|
| |
llvm-svn: 223821
|
| |
|
|
| |
llvm-svn: 223820
|
| |
|
|
|
|
|
|
|
| |
The load/store value type is currently not available when lowering the memcpy
intrinsic. Add the missing nullptr check to support this in 'computeAddress'.
Fixes rdar://problem/19178947.
llvm-svn: 223818
|
| |
|
|
| |
llvm-svn: 223815
|