| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 122794
|
|
|
|
| |
llvm-svn: 122789
|
|
|
|
|
|
|
|
|
| |
earlyclobber stuff. This should fix PRs 2313 and 8157.
Unfortunately, no testcase, since it'd be dependent on register
assignments.
llvm-svn: 122663
|
|
|
|
|
|
| |
files in Target/ARM and Target/X86.
llvm-svn: 122623
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DAG scheduling during isel. Most new functionality is currently
guarded by -enable-sched-cycles and -enable-sched-hazard.
Added InstrItineraryData::IssueWidth field, currently derived from
ARM itineraries, but could be initialized differently on other targets.
Added ScheduleHazardRecognizer::MaxLookAhead to indicate whether it is
active, and if so how many cycles of state it holds.
Added SchedulingPriorityQueue::HasReadyFilter to allowing gating entry
into the scheduler's available queue.
ScoreboardHazardRecognizer now accesses the ScheduleDAG in order to
get information about it's SUnits, provides RecedeCycle for bottom-up
scheduling, correctly computes scoreboard depth, tracks IssueCount, and
considers potential stall cycles when checking for hazards.
ScheduleDAGRRList now models machine cycles and hazards (under
flags). It tracks MinAvailableCycle, drives the hazard recognizer and
priority queue's ready filter, manages a new PendingQueue, properly
accounts for stall cycles, etc.
llvm-svn: 122541
|
|
|
|
| |
llvm-svn: 122539
|
|
|
|
| |
llvm-svn: 122530
|
|
|
|
| |
llvm-svn: 122524
|
|
|
|
| |
llvm-svn: 122523
|
|
|
|
|
|
|
|
| |
If the basic block containing the BCCi64 (or BCCZi64) instruction ends with
an unconditional branch, that branch needs to be deleted before appending
the expansion of the BCCi64 to the end of the block.
llvm-svn: 122521
|
|
|
|
| |
llvm-svn: 122513
|
|
|
|
| |
llvm-svn: 122456
|
|
|
|
|
|
|
|
|
|
|
| |
Type legalization splits up i64 values into pairs of i32 values, which leads
to poor quality code when inserting or extracting i64 vector elements.
If the vector element is loaded or stored, it can be treated as an f64 value
and loaded or stored directly from a VPR register. Use the pre-legalization
DAG combiner to cast those vector elements to f64 types so that the type
legalizer won't mess them up. Radar 8755338.
llvm-svn: 122319
|
|
|
|
|
|
| |
Fixes rdar://8782223
llvm-svn: 122313
|
|
|
|
|
|
|
| |
something that just glues two nodes together, even if it is
sometimes used for flags.
llvm-svn: 122310
|
|
|
|
|
|
|
|
|
| |
to be the one we want to use. bugpoint reduced testcase is a little large,
I'll see if I can simplify it down more.
Fixes part of rdar://8782207
llvm-svn: 122307
|
|
|
|
|
|
|
|
|
| |
tPseudoInst class, its size was changed from "special" to "2 bytes". This is
incorrect because the jump table will no longer be taken into account when
calculating branch offsets.
<rdar://problem/8782216>
llvm-svn: 122303
|
|
|
|
| |
llvm-svn: 122302
|
|
|
|
| |
llvm-svn: 122147
|
|
|
|
| |
llvm-svn: 122134
|
|
|
|
|
|
|
|
|
|
|
| |
ARM::tMOVgpr2gpr. But this check didn't change. As a result, we were getting
misaligned references to the jump table from an ADR instruction.
There is a test case, but unfortunately it's sensitive to random code changes.
<rdar://problem/8782223>
llvm-svn: 122131
|
|
|
|
| |
llvm-svn: 122129
|
|
|
|
| |
llvm-svn: 122119
|
|
|
|
|
|
| |
The result vector elements are always integers. Radar 8782191.
llvm-svn: 122112
|
|
|
|
| |
llvm-svn: 122111
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
may be called. If the entry block is empty, the insertion point iterator will be
the "end()" value. Calling ->getParent() on it (among others) causes problems.
Modify materializeFrameBaseRegister to take the machine basic block and insert
the frame base register at the beginning of that block. (It's very similar to
what the code does all ready. The only difference is that it will always insert
at the beginning of the entry block instead of after a previous materialization
of the frame base register. I doubt that that matters here.)
<rdar://problem/8782198>
llvm-svn: 122104
|
|
|
|
|
|
|
| |
The standard error handling in AsmPrinter::EmitInlineAsm handles this much
better, so just use it.
llvm-svn: 122100
|
|
|
|
|
|
| |
a partial value. rdar://8782954
llvm-svn: 122078
|
|
|
|
| |
llvm-svn: 122076
|
|
|
|
| |
llvm-svn: 122075
|
|
|
|
| |
llvm-svn: 122067
|
|
|
|
| |
llvm-svn: 122064
|
|
|
|
| |
llvm-svn: 122044
|
|
|
|
|
|
| |
superceded and was effectively dead.
llvm-svn: 122024
|
|
|
|
| |
llvm-svn: 122017
|
|
|
|
| |
llvm-svn: 121990
|
|
|
|
|
|
| |
interface.
llvm-svn: 121981
|
|
|
|
| |
llvm-svn: 121973
|
|
|
|
| |
llvm-svn: 121971
|
|
|
|
|
|
|
| |
the MCCodeEmitter, which seems like a better organization.
- Also, cleaned up some magic constants while in the area.
llvm-svn: 121953
|
|
|
|
|
|
| |
(see PR4579).
llvm-svn: 121939
|
|
|
|
|
|
| |
it. I.e., it was always an immediate value.
llvm-svn: 121932
|
|
|
|
|
|
|
|
|
| |
respectively.
It may be a bug that these opcodes are getting this far into machine code
generation.
llvm-svn: 121931
|
|
|
|
| |
llvm-svn: 121929
|
|
|
|
|
|
| |
Canonicalize on tLDRpci and remove tLDRcp.
llvm-svn: 121920
|
|
|
|
| |
llvm-svn: 121919
|
|
|
|
|
|
| |
need to use tLDRi and tSTRi instead of tLDRspi and tSTRspi respectively.
llvm-svn: 121915
|
|
|
|
| |
llvm-svn: 121914
|
|
|
|
|
|
|
| |
Clang is now providing intrinsics for these and so we need to support them
in the backend. Radar 8068427.
llvm-svn: 121902
|
|
|
|
| |
llvm-svn: 121878
|