| Commit message (Collapse) | Author | Age | Files | Lines | 
| | 
| 
| 
| 
| 
|  | 
instructions. This way the assembler will perform range checking. Believe this matches gas behavior.
llvm-svn: 250016
 | 
| | 
| 
| 
| 
| 
|  | 
%xmmX, %xmmX encoding if it would be a shorter VEX encoding.
llvm-svn: 250014
 | 
| | 
| 
| 
|  | 
llvm-svn: 250013
 | 
| | 
| 
| 
| 
| 
|  | 
parser will check the size.
llvm-svn: 250012
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
arithmetic instructions with 8-bit immediates over the forms that implicitly use the ax/eax/rax.
This allows us to remove the explicit code for working around the existing priority
llvm-svn: 250011
 | 
| | 
| 
| 
| 
| 
|  | 
al/ax/eax/rax as a def. Probably doesn't have a functional affect since these aren't used in isel.
llvm-svn: 249994
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
Enabled constant canonicalization for all constants.
Improved combining of constant vectors.
llvm-svn: 249993
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
Instead mark its operand type as u8imm which will cause it to fail to match. This is more consistent with other instruction behavior.
This also fixes a bug where negative immediates below -128 were not being reported as errors.
llvm-svn: 249989
 | 
| | 
| 
| 
|  | 
llvm-svn: 249979
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
Enable constant folding for vector splats as well as scalars.
Enable constant canonicalization for all scalar and vector constants.
llvm-svn: 249978
 | 
| | 
| 
| 
| 
| 
|  | 
We now have lowering support for XOP PCOM/PCOMU instructions.
llvm-svn: 249977
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
comparisons to XOP PCOM/PCOMU instructions.
The XOP vector integer comparisons can deal with all signed/unsigned comparison cases directly and can be easily commuted as well (D7646).
llvm-svn: 249976
 | 
| | 
| 
| 
| 
| 
|  | 
This is a test of the LLVM commit system. In the event of a real commit there would be some useful code changes.
llvm-svn: 249972
 | 
| | 
| 
| 
|  | 
llvm-svn: 249952
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary:
The change to use the VST function entries for lazy deserialization did
not handle the case of anonymous functions without aliases. In that case
we must fall back to scanning the function blocks as there is no VST
entry.
Reviewers: dexonsmith, joker.eph, davidxl
Subscribers: tstellarAMD, llvm-commits
Differential Revision: http://reviews.llvm.org/D13596
llvm-svn: 249947
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
expandPostRAPseudo():
STX -> 2 * STD: The first STD should not have the kill flag set for the address.
SystemZElimCompare:
BRC -> BRCT conversion: Don't forget to remove the CC<use,kill> operand.
Needed to make SystemZ/asm-17.ll pass with -verify-machineinstrs, which
now runs with this flag.
Reviewed by Ulrich Weigand.
llvm-svn: 249945
 | 
| | 
| 
| 
|  | 
llvm-svn: 249944
 | 
| | 
| 
| 
|  | 
llvm-svn: 249943
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary:
Rather than just iterating over all sections and checking whether we have relocations for them, iterate over the relocation map instead. This showed up heavily in an artificial julia benchmark that does lots of compilation. On that particular benchmark, this patch gives
~15% performance improvements. As far as I can tell the primary reason why the original
loop was so expensive is that Relocations[i] actually constructs a relocationList (allocating memory & doing lots of other unnecessary computing) if none is found.
Reviewers: lhames
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D13545
llvm-svn: 249942
 | 
| | 
| 
| 
|  | 
llvm-svn: 249941
 | 
| | 
| 
| 
|  | 
llvm-svn: 249940
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Remove implicit ilist iterator conversions from LLVMAnalysis.
I came across something really scary in `llvm::isKnownNotFullPoison()`
which relied on `Instruction::getNextNode()` being completely broken
(not surprising, but scary nevertheless).  This function is documented
(and coded to) return `nullptr` when it gets to the sentinel, but with
an `ilist_half_node` as a sentinel, the sentinel check looks into some
other memory and we don't recognize we've hit the end.
Rooting out these scary cases is the reason I'm removing the implicit
conversions before doing anything else with `ilist`; I'm not at all
surprised that clients rely on badness.
I found another scary case -- this time, not relying on badness, just
bad (but I guess getting lucky so far) -- in
`ObjectSizeOffsetEvaluator::compute_()`.  Here, we save out the
insertion point, do some things, and then restore it.  Previously, we
let the iterator auto-convert to `Instruction*`, and then set it back
using the `Instruction*` version:
    Instruction *PrevInsertPoint = Builder.GetInsertPoint();
    /* Logic that may change insert point */
    if (PrevInsertPoint)
      Builder.SetInsertPoint(PrevInsertPoint);
The check for `PrevInsertPoint` doesn't protect correctly against bad
accesses.  If the insertion point has been set to the end of a basic
block (i.e., `SetInsertPoint(SomeBB)`), then `GetInsertPoint()` returns
an iterator pointing at the list sentinel.  The version of
`SetInsertPoint()` that's getting called will then call
`PrevInsertPoint->getParent()`, which explodes horribly.  The only
reason this hasn't blown up is that it's fairly unlikely the builder is
adding to the end of the block; usually, we're adding instructions
somewhere before the terminator.
llvm-svn: 249925
 | 
| | 
| 
| 
|  | 
llvm-svn: 249922
 | 
| | 
| 
| 
| 
| 
|  | 
wineh-parent is dead, so is ValueOrMBB.
llvm-svn: 249920
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
The new implementation works at least as well as the old implementation
did.
Also delete the associated preparation tests. They don't exercise
interesting corner cases of the new implementation. All the codegen
tests of the EH tables have already been ported.
llvm-svn: 249918
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
Also Fix a buglet where SEH tables had ranges that spanned funclets.
The remaining tests using the old landingpad IR are preparation tests,
and will be deleted along with the old preparation.
llvm-svn: 249917
 | 
| | 
| 
| 
| 
| 
| 
|  | 
Finish removing implicit ilist iterator conversions from LLVMCodeGen.
I'm sure there are lots more of these in lib/CodeGen/*/.
llvm-svn: 249915
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
x64 catchpads use rax to inform the unwinder where control should go
next.  However, we must initialize rax before the epilogue sequence so
as to not perturb the unwinder.
llvm-svn: 249910
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This occurred due to introducing the invalid i64 type after type
legalization had already finished, in an attempt to workaround bitcast
f64 -> v2i32 not doing constant folding.
The *right* thing is to actually fix bitcast, but that has other
complications. So, for now, just get rid of the broken workaround, and
check in a test-case showing that it doesn't crash, with TODOs for
emitting proper code.
llvm-svn: 249908
 | 
| | 
| 
| 
| 
| 
| 
|  | 
We got them right for the old IR, but not with funclets.  Port the old
test to the new IR and fix the code.
llvm-svn: 249906
 | 
| | 
| 
| 
|  | 
llvm-svn: 249903
 | 
| | 
| 
| 
|  | 
llvm-svn: 249901
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
This wasn't very observable in execution tests, because usually there is
an invoke in the catchpad that unwinds the the catchendpad but never
actually throws.
llvm-svn: 249898
 | 
| | 
| 
| 
|  | 
llvm-svn: 249892
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
When running combine on an extract_vector_elt, it wants to look through
a bitcast to check if the argument to the bitcast was itself an
extract_vector_elt with particular operands.
However, it called getOperand() on the argument to the bitcast *before*
checking that the opcode was EXTRACT_VECTOR_ELT, assert-failing if there
were zero operands for the actual opcode.
Fix, and add trivial test.
llvm-svn: 249891
 | 
| | 
| 
| 
| 
| 
|  | 
This reverts commit r248610.
llvm-svn: 249887
 | 
| | 
| 
| 
|  | 
llvm-svn: 249884
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Remove implicit ilist iterator conversions from MachineBasicBlock.cpp.
I've also added an overload of `splice()` that takes a pointer, since
it's a natural API.  This is similar to the overloads I added for
`remove()` and `erase()` in r249867.
llvm-svn: 249883
 | 
| | 
| 
| 
|  | 
llvm-svn: 249880
 | 
| | 
| 
| 
|  | 
llvm-svn: 249879
 | 
| | 
| 
| 
| 
| 
|  | 
This happens to avoid a host of implicit ilist iterator conversions.
llvm-svn: 249877
 | 
| | 
| 
| 
|  | 
llvm-svn: 249876
 | 
| | 
| 
| 
|  | 
llvm-svn: 249875
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
containing convergent operations.
Doing so could cause the post-unswitching convergent ops to be
control-dependent on the unswitch condition where they were not before.
This check could be refined to allow unswitching where the convergent
operation was already control-dependent on the unswitch condition.
llvm-svn: 249874
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Remove a few more implicit ilist iterator conversions, this time from
Analysis.cpp and BranchFolding.cpp.
I added a few overloads for `remove()` and `erase()`, which quite
naturally take pointers as well as iterators as parameters.  This will
reduce the churn at least in the short term, but I don't really have a
problem with these existing for longer.
llvm-svn: 249867
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
control dependencies.
This covers the common case of operations that cannot be sunk.
Operations that cannot be hoisted should already be handled properly via
the safe-to-speculate rules and mechanisms.
llvm-svn: 249865
 | 
| | 
| 
| 
|  | 
llvm-svn: 249863
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
With this patch we can now read and write inline stacks in sample
profiles to the binary encoded profiles.
In a subsequent patch, I will add a string table to the binary encoding.
Right now function names are emitted as strings every time we find them.
This is too bloated and will produce large files in applications with
lots of inlining.
llvm-svn: 249861
 | 
| | 
| 
| 
|  | 
llvm-svn: 249859
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
metadata
Reviewed By: reames
Differential Revision: http://reviews.llvm.org/D13428
llvm-svn: 249856
 |