Age | Commit message (Collapse) | Author |
|
instead of hoisting them, just fold them away. This occurs in the
testcase for PR8041, for example.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112669 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
and output the dwarf line number tables. This takes the current loc info after
an instruction is assembled and saves the needed info into an object that has
vector and for each section. These objects will be used for the final patch to
build and emit the encoded dwarf line number tables. Again for now this is only
in the Mach-O streamer but at some point will move to a more generic place.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112668 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112667 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112666 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
inner loop doesn't update all the variables in the outer loop.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112665 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
int x(int t) {
if (t & 256)
return -26;
return 0;
}
We generate this:
tst.w r0, #256
mvn r0, #25
it eq
moveq r0, #0
while gcc generates this:
ands r0, r0, #256
it ne
mvnne r0, #25
bx lr
Scandalous really!
During ISel time, we can look for this particular pattern. One where we have a
"MOVCC" that uses the flag off of a CMPZ that itself is comparing an AND
instruction to 0. Something like this (greatly simplified):
%r0 = ISD::AND ...
ARMISD::CMPZ %r0, 0 @ sets [CPSR]
%r0 = ARMISD::MOVCC 0, -26 @ reads [CPSR]
All we have to do is convert the "ISD::AND" into an "ARM::ANDS" that sets [CPSR]
when it's zero. The zero value will all ready be in the %r0 register and we only
need to change it if the AND wasn't zero. Easy!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112664 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112662 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
useless load nodes
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112661 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112659 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112657 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112654 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112653 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112652 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
No CCR virtual registers should exist, and %EFLAGS is used in ways that can
surprise RegAllocFast.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112650 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Reserved registers are unpredictable, and are treated as always live by machine
DCE.
Allocatable registers are never reserved, and can be used for virtual registers.
Unreserved, unallocatable registers can not be used for virtual registers, but
otherwise behave like a normal allocatable register. Most targets only have
the flag register in this set.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112649 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
fragments
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112644 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112643 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
useless nodes
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112642 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112638 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112635 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
duplicated code into a helper function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112634 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112632 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112631 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112630 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112628 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112625 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
determining if they're likely to be in range of the SP when resolving
frame references.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112624 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
info to emit debug info.
Fixes Radar 8367011.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112623 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the offset is legally encodable, not actually trying to do the encoding.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112622 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112621 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
first failure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112620 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112617 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112615 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112613 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
I have not been able to find a way to test each in isolation, for a few reasons:
1) The ability to look-through non-i1 BinaryOperator's requires the ability to look through non-constant
ICmps in order for it to ever trigger.
2) The ability to do LVI-powered PHI value determination only matters in cases that ProcessBranchOnPHI
can't handle. Since it already handles all the cases without other instructions in the def-use chain
between the PHI and the branch, it requires the ability to look through ICmps and/or BinaryOperators
as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112611 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112610 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
1. Allocate them in the entry block of the function to enable function-wide
re-use. The instructions to create them should be re-materializable, so
there shouldn't be additional cost compared to creating them local
to the basic blocks where they are used.
2. Collect all of the frame index references for the function and sort them
by the local offset referenced. Iterate over the sorted list to
allocate the virtual base registers. This enables creation of base
registers optimized for positive-offset access of frame references.
(Note: This may be appropriate to later be a target hook to do the
sorting in a target appropriate manner. For now it's done here for
simplicity.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112609 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112608 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112605 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
any more. I plan to reimplement alloca promotion using SSAUpdater later.
It looks like Bill's URoR logic really always needs domtree, so the pass
now always asks for domtree info.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112597 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
two are weak, we make them thunks to a new strong function) so don't iterate
through the function list as we're modifying it.
Also add back the outermost loop which got removed during the cleanups.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112595 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
safely simplify instructions after each block has been processed without worrying about iterator invalidation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112594 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- Convert {0,1} and friends into 0b01, which is identical and more consistent.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112593 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112592 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112591 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112590 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
constant-fold undef, and be more careful with its return value.
This actually exposed an infinite recursion bug in ComputeValueKnownInPredecessors which theoretically already existed (in JumpThreading's
handling of and/or of i1's), but never manifested before. This patch adds a tracking set to prevent this case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112589 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112587 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
getMagicNumber was treating the _binary_ data it read in as a
null terminated string. This resulted in the std::string
calculating the length, and causing an assert in other code that
assumed that the length it passed was the same as the length of
the string it would get back.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112586 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112585 91177308-0d34-0410-b5e6-96231b3b80d8
|