safe. This can happen we a subreg_to_reg 0 has been coalesced. One
exception is when the instruction that folds the load is a move, then we
can simply turn it into a 32-bit load from the stack slot.
rdar://7170444
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81494 91177308-0d34-0410-b5e6-96231b3b80d8
to instructions instead of zero extended ones. This makes the asmprinter
print signed values more consistently. This apparently only really affects
the X86 backend.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81265 91177308-0d34-0410-b5e6-96231b3b80d8
depth first order, so it wouldn't process unreachable blocks.
When compiling at -O0, late dead block elimination isn't done
and the bad instructions got to isel.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81187 91177308-0d34-0410-b5e6-96231b3b80d8
from floating-point to integer first, and bitcast the result
back to floating-point. Previously, this test was passing by
falling back to SelectionDAG lowering. The resulting code isn't
as nice, but it's correct and CodeGen now stays on the fast path.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81171 91177308-0d34-0410-b5e6-96231b3b80d8
- I'd appreciate it if someone else eyeballs my changes to make sure I captured
the intent of the test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81083 91177308-0d34-0410-b5e6-96231b3b80d8
linear scan reg alloc. This fixes a problem I ran into where extracting
a function from a larger file caused the generated code to change (masking
the problem I was trying to debug) because the allocator behaved differently.
This changes the results for two X86 regression checks. stack-color-with-reg
is improved, with one less instruction, but pr3495 is worse, with one more
copy. As far as I can tell, these tests were just getting lucky or unlucky,
so I've changed the expected results.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81060 91177308-0d34-0410-b5e6-96231b3b80d8
tied to different source registers, the TwoAddressInstructionPass needs to
be smarter. Change it to check before replacing a source register whether
that source register is tied to a different destination register, and if so,
defer handling it until a subsequent iteration.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80654 91177308-0d34-0410-b5e6-96231b3b80d8
makes an eggregious hack somewhat more palatable. Bringing the LSDA forward
and making it a GV available for reference would be even better, but is
beyond the scope of what I'm looking to solve at this point.
Objective C++ code could generate function names that broke the previous
scheme. This fixes that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80649 91177308-0d34-0410-b5e6-96231b3b80d8
moves. This avoids the need to promote the operands (or implicitly
extend them, a partial register update condition), and can reduce
i8 register pressure. This substantially speeds up code such as
write_hex in lib/Support/raw_ostream.cpp.
subclass-coalesce.ll is too trivial and no longer tests what it was
originally intended to test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80184 91177308-0d34-0410-b5e6-96231b3b80d8
leads to partial-register definitions. To help avoid redundant
zero-extensions, also teach the h-register matching patterns that
use movzbl to match anyext as well as zext.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80099 91177308-0d34-0410-b5e6-96231b3b80d8
more and is much nicer to the OS.
- Dan, please check. If there are parts of the test you think I should strip
out so it doesn't cause random failures let me know (there are still some PIC
label numbers in it, for example).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80019 91177308-0d34-0410-b5e6-96231b3b80d8
code, according to Anton (I'm not totally convinced, but we can always
resurrect patches if we need to do so.)
- Start moving CellSPU's tests to prefer FileCheck.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79958 91177308-0d34-0410-b5e6-96231b3b80d8
all Darwin targets; could be split into separate tests for
the chip subdirectories, but from Chris' last mail on testing
I assume he'd rather have only one test. Generic seems to be
the best available, maybe there should be a Darwin subdirectory?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79877 91177308-0d34-0410-b5e6-96231b3b80d8
When undoing a reuse in ReuseInfo::GetRegForReload, check if it was only a
sub-register being used. The MachineOperand::getSubReg() method is only valid
for virtual registers, so we have to recover the sub-register index manually.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79855 91177308-0d34-0410-b5e6-96231b3b80d8
vector shuffles. Temporarily remove the tests for these operations until the
new implementation is working.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79579 91177308-0d34-0410-b5e6-96231b3b80d8
over absolute addressing even in non-PIC mode (unless the address
has an index or something else incompatible), because it has a
smaller encoding.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79553 91177308-0d34-0410-b5e6-96231b3b80d8
This is derived from a patch by Anton Korzh. I modified it to recognize
the VEXT shuffles during legalization and lower them to a target-specific
DAG node.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79428 91177308-0d34-0410-b5e6-96231b3b80d8
remove RemoveDuplicateSuccessor, as it is no longer necessary, and because
it breaks assumptions made in
MachineBasicBlock::isOnlyReachableByFallthrough.
Convert test/CodeGen/X86/omit-label.ll to FileCheck and add a testcase
for PR4732.
test/CodeGen/Thumb2/thumb2-ifcvt2.ll sees a diff with this commit due to
it being bugpoint-reduced to the point where it doesn't matter what the
condition for the branch is.
Add some more interesting code to
test/CodeGen/X86/2009-08-06-branchfolder-crash.ll, which is the testcase
that originally motivated the RemoveDuplicateSuccessor code, to help
verify that the original problem isn't being re-broken.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79338 91177308-0d34-0410-b5e6-96231b3b80d8
for a single "m" constraint; this is wrong because the
opcode of a load or store would have to change in parallel.
This patch makes it always compute addresses into a register,
which is correct but not as efficient as possible. 7144566.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79292 91177308-0d34-0410-b5e6-96231b3b80d8
support unaligned mem access only for certain types. (Should it be size
instead?)
ARM v7 supports unaligned access for i16 and i32, some v6 variants support it
as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79127 91177308-0d34-0410-b5e6-96231b3b80d8
It is legal for an inline asm operand to use an earlyclobber register if the
use operand is tied to the earlyclobber operand. The issue is discussed here:
http://gcc.gnu.org/ml/gcc/1999-04n/msg00431.html
We should perhaps let only the machine code verifier worry about these finer
details. EarlyClobber operands are not really interesting to the scavenger.
This fixes PR4528 for the third time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79122 91177308-0d34-0410-b5e6-96231b3b80d8
In a naked function, the flag is never set and getPristineRegs() returns an
empty list. That means naked functions are able to clobber callee saved
registers, but that is the whole point of naked functions.
This fixes PR4716.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79096 91177308-0d34-0410-b5e6-96231b3b80d8
In the included test case, a stack load was not included in DistanceMap. That
caused TransferDeadness to ignore the instruction, leading to a scavenger
assert.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79090 91177308-0d34-0410-b5e6-96231b3b80d8
support for globals going into the appropriate sections with the flags.
This hopefully finishes unbreaking the previous behavior that I broke before.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79079 91177308-0d34-0410-b5e6-96231b3b80d8
the register save area if %al is 0. This avoids touching xmm
regsiters when they aren't actually used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79061 91177308-0d34-0410-b5e6-96231b3b80d8
x86_64-apple-darwin10.
--- Reverse-merging r78895 into '.':
U test/CodeGen/PowerPC/2008-12-12-EH.ll
U lib/Target/DarwinTargetAsmInfo.cpp
--- Reverse-merging r78892 into '.':
U include/llvm/Target/DarwinTargetAsmInfo.h
U lib/Target/X86/X86TargetAsmInfo.cpp
U lib/Target/X86/X86TargetAsmInfo.h
U lib/Target/ARM/ARMTargetAsmInfo.h
U lib/Target/ARM/ARMTargetMachine.cpp
U lib/Target/ARM/ARMTargetAsmInfo.cpp
U lib/Target/PowerPC/PPCTargetAsmInfo.cpp
U lib/Target/PowerPC/PPCTargetAsmInfo.h
U lib/Target/PowerPC/PPCTargetMachine.cpp
G lib/Target/DarwinTargetAsmInfo.cpp
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78919 91177308-0d34-0410-b5e6-96231b3b80d8
implemented somewhat differently than before, but it should have
the same functionality and the previous testcase passes again.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78900 91177308-0d34-0410-b5e6-96231b3b80d8
syntactically as a string, very similiar to what Chris did with MachO.
The parsing support and validation is not introduced yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78890 91177308-0d34-0410-b5e6-96231b3b80d8
The register scavenger maintains a DistanceMap that maps MI pointers to their
distance from the top of the current MBB. The DistanceMap is built
incrementally in forward() and in bulk in findFirstUse(). It is used by
scavengeRegister() to determine which candidate register has the longest
unused interval.
Unfortunately the DistanceMap contents can become outdated. The first time
scavengeRegister() is called, the DistanceMap is filled to cover the MBB. If
then instructions are inserted in the MBB (as they always are following
scavengeRegister()), the recorded distances are too short. This causes bad
behaviour in the included test case where a register use /after/ the current
position is ignored because findFirstUse() thinks is is /before/ the current
position. A "using an undefined register" assertion follows promptly.
The fix is to build a fresh DistanceMap at the top of scavengeRegister(), and
discard it after use. This means that DistanceMap is no longer needed as a
RegScavenger member variable, and forward() doesn't need to update it.
The fix then discloses issue number two in the same test case: The candidate
search in scavengeRegister() finds a CSR that has been saved in the prologue,
but is currently unused. It would be both inefficient and wrong to spill such
a register in the emergency spill slot. In the present case, the emergency
slot restore is placed immediately before the normal epilogue restore, leading
to a "Redefining a live register" assertion.
Fix number two: When scavengerRegister() stumbles upon an unused register that
is overwritten later in the MBB, return that register early. It is important
to verify that the register is defined later in the MBB, otherwise it might be
an unspilled CSR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78650 91177308-0d34-0410-b5e6-96231b3b80d8
the overloaded vector types allowed floating-point or integer vector elements.
Most of these operations actually depend on the element type, so bitcasting
was not an option.
If you include the vpadd intrinsics that I updated earlier, this gets rid
of 20 intrinsics.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78646 91177308-0d34-0410-b5e6-96231b3b80d8
MERGE_VALUES nodes. Replacing the result values with the
operands in one MERGE_VALUES node may cause another
MERGE_VALUES node be CSE'd with the first one, and bring
its uses along, so that the first one isn't dead, as this
code expects. Fix this by iterating until the node is
really dead. This fixes PR4699.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78619 91177308-0d34-0410-b5e6-96231b3b80d8
instead of syntactically as a string. This means that it keeps track of the
segment, section, flags, etc directly and asmprints them in the right format.
This also includes parsing and validation support for llvm-mc and
"attribute(section)", so we should now start getting errors about invalid
section attributes from the compiler instead of the assembler on darwin.
Still todo:
1) Uniquing of darwin mcsections
2) Move all the Darwin stuff out to MCSectionMachO.[cpp|h]
3) there are a few FIXMEs, for example what is the syntax to get the
S_GB_ZEROFILL segment type?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78547 91177308-0d34-0410-b5e6-96231b3b80d8
bytes for F2 0F 38 and propagate. Add a FIXME for a set
of possibilities which correspond to intrinsics already used.
New test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78508 91177308-0d34-0410-b5e6-96231b3b80d8
Blackfin supports and/or/xor on i32 but not on i16. Teach
DAGCombiner::SimplifyBinOpWithSameOpcodeHands to not produce illegal nodes
after legalize ops.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78497 91177308-0d34-0410-b5e6-96231b3b80d8
Verify that early clobber registers and their aliases are not used.
All changes to RegsAvailable are now done as a transaction so the order of
operands makes no difference.
The included test case is from PR4686. It has behaviour that was dependent on the order of operands.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78465 91177308-0d34-0410-b5e6-96231b3b80d8
This patch takes pain to ensure all the PEI lowering code does the right thing when lowering frame indices, insert code to manipulate stack pointers, etc. It's also custom lowering dynamic stack alloc into pseudo instructions so we can insert the right instructions at scheduling time.
This fixes PR4659 and PR4682.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78361 91177308-0d34-0410-b5e6-96231b3b80d8
