| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 159112
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are patterns to handle immediates when they fit in the immediate field.
e.g. %sub = add i32 %x, -123
=> sub r0, r0, #123
Add patterns to catch immediates that do not fit but should be materialized
with a single movw instruction rather than movw + movt pair.
e.g. %sub = add i32 %x, -65535
=> movw r1, #65535
sub r0, r0, r1
rdar://11726136
llvm-svn: 159057
|
| |
|
|
|
|
|
|
|
|
|
| |
As an example of how the custom DiagnosticType can be used to provide
better operand-mismatch diagnostics, add a custom diagnostic for
the imm0_15 operand class used for several system instructions.
Update the tests to expect the improved diagnostic.
rdar://8987109
llvm-svn: 159051
|
| |
|
|
|
|
|
|
| |
This makes it explicit when ScoreboardHazardRecognizer will be used.
"GenericItineraries" would only make sense if it contained real
itinerary values and still required ScoreboardHazardRecognizer.
llvm-svn: 158963
|
| |
|
|
|
|
|
|
|
|
| |
This is a minor drive-by fix with no robust way to unit test.
As an example see neon-div.ll:
SU(16): %Q8<def> = VMOVLsv4i32 %D17, pred:14, pred:%noreg, %Q8<imp-use,kill>
val SU(1): Latency=2 Reg=%Q8
...should be latency=1
llvm-svn: 158960
|
| |
|
|
|
|
|
|
| |
Minor drive by fix to cleanup latency computation. Calling
getOperandLatency with a deliberately incorrect operand index does not
give you the latency you want.
llvm-svn: 158959
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
boolean flag to an enum: { Fast, Standard, Strict } (default = Standard).
This option controls the creation by optimizations of fused FP ops that store
intermediate results in higher precision than IEEE allows (E.g. FMAs). The
behavior of this option is intended to match the behaviour specified by a
soon-to-be-introduced frontend flag: '-ffuse-fp-ops'.
Fast mode - allows formation of fused FP ops whenever they're profitable.
Standard mode - allow fusion only for 'blessed' FP ops. At present the only
blessed op is the fmuladd intrinsic. In the future more blessed ops may be
added.
Strict mode - allow fusion only if/when it can be proven that the excess
precision won't effect the result.
Note: This option only controls formation of fused ops by the optimizers. Fused
operations that are explicitly requested (e.g. FMA via the llvm.fma.* intrinsic)
will always be honored, regardless of the value of this option.
Internally TargetOptions::AllowExcessFPPrecision has been replaced by
TargetOptions::AllowFPOpFusion.
llvm-svn: 158956
|
| |
|
|
| |
llvm-svn: 158902
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds DAG combines to form FMAs from pairs of FADD + FMUL or
FSUB + FMUL. The combines are performed when:
(a) Either
AllowExcessFPPrecision option (-enable-excess-fp-precision for llc)
OR
UnsafeFPMath option (-enable-unsafe-fp-math)
are set, and
(b) TargetLoweringInfo::isFMAFasterThanMulAndAdd(VT) is true for the type of
the FADD/FSUB, and
(c) The FMUL only has one user (the FADD/FSUB).
If your target has fast FMA instructions you can make use of these combines by
overriding TargetLoweringInfo::isFMAFasterThanMulAndAdd(VT) to return true for
types supported by your FMA instruction, and adding patterns to match ISD::FMA
to your FMA instructions.
llvm-svn: 158757
|
| |
|
|
|
|
|
| |
The condition code didn't actually matter for arm "b" instructions,
unlike "bl". It should just use the R_ARM_JUMP24 reloc.
llvm-svn: 158722
|
| |
|
|
|
|
|
|
|
|
| |
TargetLoweringObjectFileELF. Use this to support it on X86. Unlike ARM,
on X86 it is not easy to find out if .init_array should be used or not, so
the decision is made via TargetOptions and defaults to off.
Add a command line option to llc that enables it.
llvm-svn: 158692
|
| |
|
|
|
|
|
|
| |
This change is to be enabled in clang.
rdar://9877866
llvm-svn: 158684
|
| |
|
|
|
|
|
|
|
|
|
| |
The NOP, WFE, WFI, SEV and YIELD instructions are all hints w/
a different immediate value in bits [7,0]. Define a generic HINT
instruction and refactor NOP, WFI, WFI, SEV and YIELD to be
assembly aliases of that.
rdar://11600518
llvm-svn: 158674
|
| |
|
|
|
|
|
|
|
|
|
| |
when a compile time constant is known. This occurs when implicitly zero
extending function arguments from 16 bits to 32 bits. The 8 bit case doesn't
need to be handled, as the 8 bit constants are encoded directly, thereby
not needing a separate load instruction to form the constant into a register.
<rdar://problem/11481151>
llvm-svn: 158659
|
| |
|
|
|
|
| |
iaspr, espr and xpsr which also needed to have 0b10 in their mask encoding bits.
llvm-svn: 158560
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch will optimize abs(x-y)
FROM
sub, movs, rsbmi
TO
subs, rsbmi
For abs, we will use cmp instead of movs. This is necessary because we already
have an existing peephole pass which optimizes away cmp following sub.
rdar: 11633193
llvm-svn: 158551
|
| |
|
|
|
|
| |
This probably mostly shows up in bugpoint-generated code.
llvm-svn: 158527
|
| |
|
|
| |
llvm-svn: 158445
|
| |
|
|
| |
llvm-svn: 158443
|
| |
|
|
|
|
| |
Patch by Jush Lu <jush.msn@gmail.com>.
llvm-svn: 158368
|
| |
|
|
|
|
|
|
|
| |
We turned off the CMN instruction because it had semantics which we weren't
getting correct. If we are comparing with an immediate, then it's okay to use
the CMN instruction.
<rdar://problem/7569620>
llvm-svn: 158302
|
| |
|
|
| |
llvm-svn: 158164
|
| |
|
|
|
|
| |
Match expectations of the new latency API. Cleanup and make the logic consistent.
llvm-svn: 158163
|
| |
|
|
| |
llvm-svn: 158162
|
| |
|
|
| |
llvm-svn: 158161
|
| |
|
|
|
|
|
|
| |
There are some that I didn't remove this round because they looked like
obvious stubs. There are dead variables in gtest too, they should be
fixed upstream.
llvm-svn: 158090
|
| |
|
|
| |
llvm-svn: 158055
|
| |
|
|
|
|
|
| |
Minimum latency determines per-cycle scheduling groups.
Expected latency determines critical path and cost.
llvm-svn: 158021
|
| |
|
|
| |
llvm-svn: 157980
|
| |
|
|
|
|
|
|
| |
This allows a subtarget to explicitly specify the issue width and
other properties without providing pipeline stage details for every
instruction.
llvm-svn: 157979
|
| |
|
|
| |
llvm-svn: 157972
|
| |
|
|
|
|
|
|
|
| |
when a compile time constant is known. This occurs when implicitly zero
extending function arguments from 16 bits to 32 bits.
<rdar://problem/11481151>
llvm-svn: 157966
|
| |
|
|
| |
llvm-svn: 157885
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
No functional change intended.
Sorry for the churn. The iterator classes are supposed to help avoid
giant commits like this one in the future. The TableGen-produced
register lists are getting quite large, and it may be necessary to
change the table representation.
This makes it possible to do so without changing all clients (again).
llvm-svn: 157854
|
| |
|
|
|
|
| |
then DestReg is undefined.
llvm-svn: 157840
|
| |
|
|
|
|
|
|
|
| |
Factor out the expansion code into a function.
This change is to be enabled in clang.
rdar://9877866
llvm-svn: 157830
|
| |
|
|
|
|
|
|
|
|
| |
We handle struct byval by inserting a pseudo op, which will be expanded to a
loop at ExpandISelPseudos.
A separate patch for clang will be submitted to enable struct byval.
rdar://9877866
llvm-svn: 157793
|
| |
|
|
|
|
| |
This code is covered by test/CodeGen/ARM/arm-modifier.ll.
llvm-svn: 157720
|
| |
|
|
|
|
| |
Patch by Jush Lu <jush.msn@gmail.com>.
llvm-svn: 157696
|
| |
|
|
|
|
|
|
|
|
| |
to pass around a struct instead of a large set of individual values. This
cleans up the interface and allows more information to be added to the struct
for future targets without requiring changes to each and every target.
NV_CONTRIB
llvm-svn: 157479
|
| |
|
|
|
|
| |
to pass the tables around.
llvm-svn: 157373
|
| |
|
|
| |
llvm-svn: 157368
|
| |
|
|
|
|
| |
uint16_t. Simplify loop iterating over one of those tables. No functional change intended.
llvm-svn: 157367
|
| |
|
|
|
|
| |
Patch by Jush Lu <jush.msn@gmail.com>.
llvm-svn: 157336
|
| |
|
|
| |
llvm-svn: 157292
|
| |
|
|
|
|
|
|
|
|
| |
32-bit offset jump tables just use real branch instructions and so aren't
marked as data regions. We were still emitting the .end_data_region
marker though, which assert()ed.
rdar://11499158
llvm-svn: 157221
|
| |
|
|
|
|
| |
t2RSB defined the operand correctly, but tRSBS didn't.
llvm-svn: 157200
|
| |
|
|
| |
llvm-svn: 157152
|
| |
|
|
|
|
| |
They need to go on the PICLDR as the verifier points out.
llvm-svn: 157151
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use a dedicated MachO load command to annotate data-in-code regions.
This is the same format the linker produces for final executable images,
allowing consistency of representation and use of introspection tools
for both object and executable files.
Data-in-code regions are annotated via ".data_region"/".end_data_region"
directive pairs, with an optional region type.
data_region_directive := ".data_region" { region_type }
region_type := "jt8" | "jt16" | "jt32" | "jta32"
end_data_region_directive := ".end_data_region"
The previous handling of ARM-style "$d.*" labels was broken and has
been removed. Specifically, it didn't handle ARM vs. Thumb mode when
marking the end of the section.
rdar://11459456
llvm-svn: 157062
|