| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
These instructions aren't universally available, but depend on a specific
extension to the normal ARM architecture (rather than, say, v6/v7/...) so a new
feature is appropriate.
This also enables the feature by default on A-class cores which usually have
these extensions, to avoid breaking existing code and act as a sensible
default.
llvm-svn: 179171
|
|
|
|
|
|
|
|
|
|
| |
NEON is not IEEE 754 compliant, so we should avoid lowering single-precision
floating point operations with NEON unless unsafe-math is turned on. The
equivalent VFP instructions are IEEE 754 compliant, but in some cores they're
much slower, so some archs/OSs might still request it to be on by default,
such as Swift and Darwin.
llvm-svn: 177651
|
|
|
|
| |
llvm-svn: 175371
|
|
|
|
|
|
| |
new features.
llvm-svn: 175336
|
|
|
|
| |
llvm-svn: 175322
|
|
|
|
|
|
|
| |
When we're recalculating the feature set of the subtarget, we need to have the
ivars in their initial state.
llvm-svn: 175320
|
|
|
|
| |
llvm-svn: 175315
|
|
|
|
|
|
|
|
| |
More details in this thread: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130128/163783.html
Patch by JF Bastien
llvm-svn: 173943
|
|
|
|
| |
llvm-svn: 170840
|
|
|
|
|
|
|
|
|
| |
are more expensive than the non-flag setting variant. Teach thumb2 size
reduction pass to avoid generating them unless we are optimizing for size.
rdar://12892707
llvm-svn: 170728
|
|
|
|
|
|
|
|
|
| |
textually as NativeClient. Also added a link to the native client project for
readers unfamiliar with it.
A Clang patch will follow shortly.
llvm-svn: 169291
|
|
|
|
|
|
|
|
|
|
| |
missed in the first pass because the script didn't yet handle include
guards.
Note that the script is now able to handle all of these headers without
manual edits. =]
llvm-svn: 169224
|
|
|
|
| |
llvm-svn: 168933
|
|
|
|
| |
llvm-svn: 164899
|
|
|
|
| |
llvm-svn: 163803
|
|
|
|
|
|
|
| |
This replaces an existing subtarget hook on ARM and allows standard
CodeGen passes to potentially use the property.
llvm-svn: 161471
|
|
|
|
| |
llvm-svn: 161469
|
|
|
|
|
|
|
|
|
|
|
| |
predicates.
Also remove NEON2 since it's not really useful and it is confusing. If
NEON + VFP4 implies NEON2 but NEON2 doesn't imply NEON + VFP4, what does it
really mean?
rdar://10139676
llvm-svn: 154480
|
|
|
|
|
|
|
|
|
|
| |
1. The new instruction itinerary entries are not properly described.
2. The asm parser can't handle vfms and vfnms.
3. There were no assembler, disassembler test cases.
4. HasNEON2 has the wrong assembler predicate.
rdar://10139676
llvm-svn: 154456
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
direct call.
llvm-svn: 151645
|
|
|
|
|
|
| |
prediction. ...", it is breaking the Clang build during the Compiler-RT part.
llvm-svn: 151630
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the processor keeps a return addresses stack (RAS) which stores the address
and the instruction execution state of the instruction after a function-call
type branch instruction.
Calling a "noreturn" function with normal call instructions (e.g. bl) can
corrupt RAS and causes 100% return misprediction so LLVM should use a
unconditional branch instead. i.e.
mov lr, pc
b _foo
The "mov lr, pc" is issued in order to get proper backtrace.
rdar://8979299
llvm-svn: 151623
|
|
|
|
|
|
| |
MSP430, PPC, PTX, Sparc, X86, XCore.
llvm-svn: 150878
|
|
|
|
|
|
| |
Patch by Ana Pazos!
llvm-svn: 148658
|
|
|
|
| |
llvm-svn: 146981
|
|
|
|
| |
llvm-svn: 144154
|
|
|
|
| |
llvm-svn: 142338
|
|
|
|
| |
llvm-svn: 141370
|
|
|
|
|
|
|
|
|
|
|
|
| |
forgotten to commit.
Build on previous patches to successfully distinguish between an M-series and A/R-series MSR and MRS instruction. These take different mask names and have a *slightly* different opcode format.
Add decoder and disassembler tests.
Improvement on the previous patch - successfully distinguish between valid v6m and v7m masks (one is a subset of the other). The patch had to be edited slightly to apply to ToT.
llvm-svn: 140696
|
|
|
|
|
|
|
| |
instructions are more aligned than the CPU requires, and adds some additional
directives, to follow in future patches. Patch by David Meyer!
llvm-svn: 139125
|
|
|
|
| |
llvm-svn: 134627
|
|
|
|
| |
llvm-svn: 134626
|
|
|
|
| |
llvm-svn: 134606
|
|
|
|
|
|
| |
them down to MC layer. Also fix tests.
llvm-svn: 134590
|
|
|
|
|
|
| |
ARM subtarget info available to MC.
llvm-svn: 134569
|
|
|
|
| |
llvm-svn: 134281
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The DSP instructions in the Thumb2 instruction set are an optional extension
in the Cortex-M* archtitecture. When present, the implementation is considered
an "ARMv7E-M implementation," and when not, an "ARMv7-M implementation."
Add a subtarget feature hook for the v7e-m instructions and hook it up. The
cortex-m3 cpu is an example of a v7m implementation, while the cortex-m4 is
a v7e-m implementation.
rdar://9572992
llvm-svn: 134261
|
|
|
|
| |
llvm-svn: 134259
|
|
|
|
|
|
|
|
|
| |
itineraries.
- Refactor TargetSubtarget to be based on MCSubtargetInfo.
- Change tablegen generated subtarget info to initialize MCSubtargetInfo
and hide more details from targets.
llvm-svn: 134257
|
|
|
|
|
|
|
|
|
|
| |
be the first encoded as the first feature. It then uses the CPU name to look up
features / scheduling itineray even though clients know full well the CPU name
being used to query these properties.
The fix is to just have the clients explictly pass the CPU name!
llvm-svn: 134127
|
|
|
|
|
|
| |
MCInstrItineraries) into MC.
llvm-svn: 134049
|
|
|
|
| |
llvm-svn: 131739
|
|
|
|
| |
llvm-svn: 131708
|
|
|
|
| |
llvm-svn: 129884
|
|
|
|
|
|
| |
predicates.
llvm-svn: 129816
|
|
|
|
|
|
|
| |
(and add false dependency) when it isn't dependent on last CPSR defining
instruction. rdar://8928208
llvm-svn: 129773
|
|
|
|
|
|
|
|
|
|
|
| |
accumulator forwarding:
vadd d3, d0, d1
vmul d3, d3, d2
=>
vmul d3, d0, d2
vmla d3, d1, d2
llvm-svn: 128665
|
|
|
|
| |
llvm-svn: 123276
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|