Same sort of bug as on ARM where the cmp+branch are lowered to br_cc
(choosing the branch's debugloc for the br_cc's debugloc) then expanded
out to a cmp and a br, but both using the debug loc of the br_cc, thus
losing fidelity.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227645 91177308-0d34-0410-b5e6-96231b3b80d8
Patch by: Igor Laevsky
"Statepoint verifier tests were using wrong names for the statepoint and gc.relocate intrinsics. This change renames them to use correct names and fixes all uncovered issues."
Differential Revision: http://reviews.llvm.org/D7266
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227636 91177308-0d34-0410-b5e6-96231b3b80d8
Some of those didn't even have run lines: they were removed
inadvertently during the Great Merge of 2014.
They used to check for DUPs, but now we go through W-regs?
Filed PR22418 for that potential regression.
For now, just make the tests explicit, so we now where we stand.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227635 91177308-0d34-0410-b5e6-96231b3b80d8
Also revert r227489 since it didn't actually fix the thing I thought I
was fixing (since the test case was targeting the wrong architecture
initially). The change might be correct & demonstrated by other test
cases, but it's not a priority for me to find those test cases right
now.
Filed PR22417 for the failure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227632 91177308-0d34-0410-b5e6-96231b3b80d8
Add tie breaker to colorChainSet() sort so that processing order doesn't
depend on std::set order, which depends on pointer order, which is
unstable from run to run.
No test case as this is nearly impossible to reproduce.
Phabricator Review: http://reviews.llvm.org/D7265
Patch by Geoff Berry <gberry@codeaurora.org>!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227606 91177308-0d34-0410-b5e6-96231b3b80d8
If the original FPU specification involved a restricted VFP unit (d16), ensure
that we reset the functionality when we encounter a new FPU type. In
particular, if the user specified vfpv3-d16, but switched to a VFPv3 (which has
32 double precision registers), we would fail to reset the D16 feature, and
treat it as being equivalent to vfpv3-d16.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227603 91177308-0d34-0410-b5e6-96231b3b80d8
I thought it was enough to just not add the tool subdirectory,
but apparently I need to explicitly mark it ignore.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227587 91177308-0d34-0410-b5e6-96231b3b80d8
In preparation for adding PDB support to LLVM, this moves the
DWARF parsing code to its own subdirectory under DebugInfo, and
renames LLVMDebugInfo to LLVMDebugInfoDWARF.
This is purely a mechanical / build system change.
Differential Revision: http://reviews.llvm.org/D7269
Reviewed by: Eric Christopher
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227586 91177308-0d34-0410-b5e6-96231b3b80d8
The FPU directive permits the user to switch the target FPU, enabling
instructions that would be otherwise unavailable. However, when configuring the
new subtarget features, we would not enable the implied functions for newer
FPUs. This would result in invalid rejection of valid input. Ensure that we
inherit the implied FPU functionality when enabling newer versions of the FPU.
Fortunately, these are mostly hierarchical, unlike the CPUs.
Addresses PR22395.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227584 91177308-0d34-0410-b5e6-96231b3b80d8
analyses back into the LTO code generator.
The pass manager builder (and the transforms library in general)
shouldn't be referencing the target machine at all.
This makes the LTO population work like the others -- the data layout
and target transform info need to be pre-populated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227576 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is needed by the .cprestore assembler directive.
This directive needs to be able to insert an LW instruction after every JALR replacement of a JAL pseudo-instruction
(and never after a JALR which has NOT been a result of a pseudo-instruction replacement).
The problem with using InstAlias for these is that after it replaces the pseudo-instruction, we can't find out if the resulting JALR instruction
was generated by an InstAlias or not, so we don't know whether or not to insert our LW instruction.
By replacing it manually, we know when the pseudo-instruction replacement happens and we can insert the LW instruction correctly.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: emaste, llvm-commits
Differential Revision: http://reviews.llvm.org/D5601
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227568 91177308-0d34-0410-b5e6-96231b3b80d8
