| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 152136
|
| |
|
|
| |
llvm-svn: 152131
|
| |
|
|
| |
llvm-svn: 152129
|
| |
|
|
| |
llvm-svn: 152127
|
| |
|
|
| |
llvm-svn: 152122
|
| |
|
|
|
|
| |
implementation. Patch by Meador Inge
llvm-svn: 152116
|
| |
|
|
|
|
|
|
|
|
| |
When an instruction only writes sub-registers, it is still necessary to
add an <imp-def> operand for the super-register. When reloading into a
virtual register, rewriting will add the operand, but when loading
directly into a virtual register, the <imp-def> operand is still
necessary.
llvm-svn: 152095
|
| |
|
|
| |
llvm-svn: 152089
|
| |
|
|
|
|
| |
providing a default expansion (FADD+FNEG), and teaching DAGCombine not to form FSUBs post-legalize if they are not legal.
llvm-svn: 152079
|
| |
|
|
|
|
|
|
|
| |
The fpscr register contains both flags (set by FP operations/comparisons) and
control bits. The control bits (FPSCR) should be reserved, since they're always
available and needn't be defined before use. The flag bits (FPSCR_NZCV) should
like to be unreserved so they can be hoisted by MachineCSE. This fixes PR12165.
llvm-svn: 152076
|
| |
|
|
| |
llvm-svn: 152070
|
| |
|
|
|
|
| |
rdar://10988114
llvm-svn: 152068
|
| |
|
|
| |
llvm-svn: 152066
|
| |
|
|
|
|
| |
Use the new composite physical registers.
llvm-svn: 152063
|
| |
|
|
| |
llvm-svn: 152061
|
| |
|
|
|
|
|
|
|
| |
With the new composite physical registers to represent arbitrary pairs
of DPR registers, we don't need the pseudo-registers anymore. Get rid of
a bunch of them that use DPR register pairs and just use the real
instructions directly instead.
llvm-svn: 152045
|
| |
|
|
|
|
|
| |
Used to allow context sensitive printing of super-register or sub-register
references.
llvm-svn: 152043
|
| |
|
|
|
|
| |
Patch by Sean Silva!
llvm-svn: 152042
|
| |
|
|
|
|
|
|
|
| |
Specifically, remove the magic number when checking to see if the copy has a
glue operand and simplify the checking logic.
rdar://10930395
llvm-svn: 152041
|
| |
|
|
|
|
|
|
|
|
|
| |
In this update:
- I assumed neon2 does not imply vfpv4, but neon and vfpv4 imply neon2.
- I kept setting .fpu=neon-vfpv4 code attribute because that is what the
assembler understands.
Patch by Ana Pazos <apazos@codeaurora.org>
llvm-svn: 152036
|
| |
|
|
| |
llvm-svn: 152035
|
| |
|
|
| |
llvm-svn: 152034
|
| |
|
|
| |
llvm-svn: 152027
|
| |
|
|
| |
llvm-svn: 152026
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implicitly fixes a nasty bug in the GVN hashing (that thankfully
could only manifest as a performance bug): actually include the opcode
in the hash. The old code started the hash off with the opcode, but then
overwrote it with the type pointer.
Since this is likely to be pretty hot (GVN being already pretty
expensive) I've included a micro-optimization to just not bother with
the varargs hashing if they aren't present. I can't measure any change
in GVN performance due to this, even with a big test case like Duncan's
sqlite one. Everything I see is in the noise floor. That said, this
closes a loop hole for a potential scaling problem due to collisions if
the opcode were the differentiating aspect of the expression.
llvm-svn: 152025
|
| |
|
|
|
|
|
|
| |
hashing infrastructure. I wonder why we don't just use StringMap here,
and I may revisit the issue if I have time, but for now I'm just trying
to consolidate.
llvm-svn: 152023
|
| |
|
|
|
|
| |
static data size.
llvm-svn: 152016
|
| |
|
|
| |
llvm-svn: 152014
|
| |
|
|
|
|
|
|
| |
The first def of a virtual register cannot also read the register.
Assert on such bad machine code instead of trying to fix it.
TwoAddressInstructionPass should never create code like that.
llvm-svn: 152010
|
| |
|
|
|
|
|
| |
We are already setting <undef> flags, and that is good enough. The
<imp-def> operands don't mean anything any more.
llvm-svn: 152009
|
| |
|
|
|
|
|
|
|
|
|
| |
MachineOperands that define part of a virtual register must have an
<undef> flag if they are not intended as read-modify-write operands.
The old trick of adding an <imp-def> operand doesn't work any longer.
Fixes PR12177.
llvm-svn: 152008
|
| |
|
|
|
|
|
|
|
|
| |
equalities into phi node operands for which the equality is known to
hold in the incoming basic block. That's because replaceAllDominatedUsesWith
wasn't handling phi nodes correctly in general (that this didn't give wrong
results was just luck: the specific way GVN uses replaceAllDominatedUsesWith
precluded wrong changes to phi nodes).
llvm-svn: 152006
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
new hash_value infrastructure, and replace their implementations using
hash_combine. This removes a complete copy of Jenkin's lookup3 hash
function (which is both significantly slower and lower quality than the
one implemented in hash_combine) along with a somewhat scary xor-only
hash function.
Now that APInt and APFloat can be passed directly to hash_combine,
simplify the rest of the LLVMContextImpl hashing to use the new
infrastructure.
llvm-svn: 152004
|
| |
|
|
| |
llvm-svn: 152003
|
| |
|
|
|
|
|
|
| |
Some BBs can become dead after codegen preparation. If we delete them here, it
could help enable tail-call optimizations later on.
<rdar://problem/10256573>
llvm-svn: 152002
|
| |
|
|
| |
llvm-svn: 152001
|
| |
|
|
|
|
| |
static data size.
llvm-svn: 151998
|
| |
|
|
|
|
| |
size of static data.
llvm-svn: 151996
|
| |
|
|
|
|
| |
Shaves 150k off the size of X86DisassemblerDecoder.o
llvm-svn: 151995
|
| |
|
|
| |
llvm-svn: 151979
|
| |
|
|
| |
llvm-svn: 151973
|
| |
|
|
|
|
|
|
|
|
| |
forming constant ranges.
This could probably be made a lot smarter, but this is a common case and doesn't require LVI to scan a lot
of code. With this change CVP can optimize away the "shift == 0" case in Hashing.h that only gets hit when
"shift" is in a range not containing 0.
llvm-svn: 151919
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change replaces getTypeStoreSize with getTypeAllocSize in AddressSanitizer
instrumentation for stack allocations.
One case where old behaviour produced undesired results is an optimization in
InstCombine pass (PromoteCastOfAllocation), which can replace alloca(T) with
alloca(S), where S has the same AllocSize, but a smaller StoreSize. Another
case is memcpy(long double => long double), where ASan will poison bytes 10-15
of a stack-allocated long double (StoreSize 10, AllocSize 16,
sizeof(long double) = 16).
See http://llvm.org/bugs/show_bug.cgi?id=12047 for more context.
llvm-svn: 151887
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In this instance we are generating the tail-call during legalizeDAG. The 2nd
floor call can't be a tail call because it clobbers %xmm1, which is defined by
the first floor call. The first floor call can't be a tail-call because it's
not in the tail position. The only reasonable way I could think to fix this
in a target-independent manner was to check for glue logic on the copy reg.
rdar://10930395
llvm-svn: 151877
|
| |
|
|
| |
llvm-svn: 151875
|
| |
|
|
| |
llvm-svn: 151874
|
| |
|
|
|
|
| |
to the string table for the function name, not the function name.
llvm-svn: 151873
|
| |
|
|
|
|
|
| |
can insert a new element, invalidating iterators. Use find
instead, and handle the case where the key is not found explicitly.
llvm-svn: 151871
|
| |
|
|
| |
llvm-svn: 151869
|
| |
|
|
|
|
|
|
|
| |
The inline table needs to be constructed ahead of time so that it doesn't try to
create new strings while we're emitting everything.
This reverts commit a8ff9bccb399183cdd5f1c3cec2bda763664b4b0.
llvm-svn: 151864
|