| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
instruction supported by mips32r2, and add a pattern which replaces bswap with
a ROTR and WSBH pair.
WSBW is removed since it is not an instruction the current architectures
support.
llvm-svn: 147015
|
| |
|
|
| |
llvm-svn: 147014
|
| |
|
|
| |
llvm-svn: 147013
|
| |
|
|
| |
llvm-svn: 147012
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
kc++ on
the build bot in some cases. The basic issue happens when a source module contains
both a "%foo" type and a "%foo.42" type. It will see the later one, check to see if
the destination module contains a "%foo" type, and it will return true... because
both the source and destination modules are in the same LLVMContext. We don't want
to map source types to other source types, so don't do the remapping if the mapped
type came from the source module.
Unfortunately, I've been unable to reduce a decent testcase for this, kc++ is
pretty great that way.
llvm-svn: 147010
|
| |
|
|
| |
llvm-svn: 147009
|
| |
|
|
|
|
|
| |
nodes needed for multiplication. Add code for selecting 64-bit MULHS and MULHU
nodes.
llvm-svn: 147008
|
| |
|
|
| |
llvm-svn: 147007
|
| |
|
|
| |
llvm-svn: 147005
|
| |
|
|
| |
llvm-svn: 147004
|
| |
|
|
| |
llvm-svn: 147003
|
| |
|
|
|
|
| |
only when the target ABI is N64.
llvm-svn: 147001
|
| |
|
|
| |
llvm-svn: 147000
|
| |
|
|
|
|
| |
MIPS64 can generate constant +0.0 with a single DMTC1 instruction.
llvm-svn: 146999
|
| |
|
|
|
|
|
|
|
|
|
| |
Use the spill slot alignment as well as the local variable alignment to
determine when the stack needs to be realigned. This works now that the
ARM target can always realign the stack by using a base pointer.
Still respect the ARMBaseRegisterInfo::canRealignStack() function
vetoing a realigned stack. Don't use aligned spill code in that case.
llvm-svn: 146997
|
| |
|
|
| |
llvm-svn: 146996
|
| |
|
|
| |
llvm-svn: 146995
|
| |
|
|
|
|
|
|
| |
enabled
only when the target ABI is N64.
llvm-svn: 146992
|
| |
|
|
| |
llvm-svn: 146990
|
| |
|
|
| |
llvm-svn: 146987
|
| |
|
|
| |
llvm-svn: 146986
|
| |
|
|
|
|
| |
Patch by Andrew Wilkins!
llvm-svn: 146984
|
| |
|
|
| |
llvm-svn: 146983
|
| |
|
|
| |
llvm-svn: 146981
|
| |
|
|
|
|
|
| |
(Both used for Linux gnueabi)
No behavioral change yet (no tests need so far)
llvm-svn: 146977
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The failure that I see in the current version is:
LLVM ERROR: Cannot select: 0x18b8f70: v4i64 = X86ISD::VZEXT_MOVL 0x18beee0 [ID=14]
0x18beee0: v4i64 = insert_subvector 0x18b8c70, 0x18b9170, 0x18b9570 [ID=13]
0x18b8c70: v4i64 = insert_subvector 0x18b9870, 0x18bf4e0, 0x18b9970 [ID=12]
0x18b9870: v4i64 = undef [ID=4]
0x18bf4e0: v2i64 = bitcast 0x18bf3e0 [ID=10]
0x18bf3e0: v4i32 = BUILD_VECTOR 0x18b9770, 0x18b9770, 0x18b9770, 0x18b9770 [ID=8]
0x18b9770: i32 = TargetConstant<0> [ID=6]
0x18b9770: i32 = TargetConstant<0> [ID=6]
0x18b9770: i32 = TargetConstant<0> [ID=6]
0x18b9770: i32 = TargetConstant<0> [ID=6]
0x18b9970: i32 = Constant<0> [ID=3]
0x18b9170: v2i64 = undef [ORD=1] [ID=1]
0x18b9570: i32 = Constant<2> [ID=5]
llvm-svn: 146975
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
use the zero-undefined variants of CTTZ and CTLZ. These are just simple
patterns for now, there is more to be done to make real world code using
these constructs be optimized and codegen'ed properly on X86.
The existing tests are spiffed up to check that we no longer generate
unnecessary cmov instructions, and that we generate the very important
'xor' to transform bsr which counts the index of the most significant
one bit to the number of leading (most significant) zero bits. Also they
now check that when the variant with defined zero result is used, the
cmov is still produced.
llvm-svn: 146974
|
| |
|
|
|
|
|
| |
Pulling the template implementation into the header to guarantee
that it's visible to all possible instantiations.
llvm-svn: 146973
|
| |
|
|
|
|
|
| |
This is the first step towards migrating more of the parser
implementation into the parser class.
llvm-svn: 146971
|
| |
|
|
| |
llvm-svn: 146968
|
| |
|
|
|
|
| |
likely to stay either way that discussion ends up resolving itself.
llvm-svn: 146966
|
| |
|
|
|
|
| |
http://llvm.org/docs/CodingStandards.html#ll_virtual_anch
llvm-svn: 146960
|
| |
|
|
|
|
| |
Fixes PR11571: Instruction does not dominate all uses
llvm-svn: 146950
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We used to rely on the *eh_sjlj_setjmp instructions to mark that a function
with setjmp/longjmp exception handling clobbers all the registers. But with
the recent reorganization of ARM EH, those eh_sjlj_setjmp instructions are
expanded away earlier, before PEI can see them to determine what registers to
save and restore. Mark the dispatchsetup instruction in the same way, since
that instruction cannot be expanded early. This also more accurately reflects
when the registers are clobbered.
llvm-svn: 146949
|
| |
|
|
|
|
|
|
|
|
| |
"mov r1, r2, lsl #0" should assemble as "mov r1, r2" even though it's
not strictly legal UAL syntax. It's a common extension and the friendly
thing to do.
rdar://10604663
llvm-svn: 146937
|
| |
|
|
|
|
|
|
| |
merging types by name when we can. We still don't guarantee type name linkage
but we do it when obviously the right thing to do. This makes LTO type names
easier to read, for example.
llvm-svn: 146932
|
| |
|
|
|
|
| |
from the source module onto the same opaque destination type. An opaque type can only be resolved to one thing or another after all.
llvm-svn: 146929
|
| |
|
|
| |
llvm-svn: 146927
|
| |
|
|
|
|
|
|
| |
e.g., "vmov.i32 d4, #-118" can be assembled as "vmvn.i32 d4, #117"
rdar://10603913
llvm-svn: 146925
|
| |
|
|
|
|
| |
rdar://9932658
llvm-svn: 146921
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unpredicated. That is, turn
subeq r0, r1, #1
addne r0, r1, #1
into
sub r0, r1, #1
addne r0, r1, #1
For targets where conditional instructions are always executed, this may be
beneficial. It may remove pseudo anti-dependency in out-of-order execution
CPUs. e.g.
op r1, ...
str r1, [r10] ; end-of-life of r1 as div result
cmp r0, #65
movne r1, #44 ; raw dependency on previous r1
moveq r1, #12
If movne is unpredicated, then
op r1, ...
str r1, [r10]
cmp r0, #65
mov r1, #44 ; r1 written unconditionally
moveq r1, #12
Both mov and moveq are no longer depdendent on the first instruction. This gives
the out-of-order execution engine more freedom to reorder them.
This has passed entire LLVM test suite. But it has not been enabled for any ARM
variant pending more performance evaluation.
rdar://8951196
llvm-svn: 146914
|
| |
|
|
|
|
| |
patterns emit a single LUi instruction instead of a pair of LUi and ORi.
llvm-svn: 146900
|
| |
|
|
| |
llvm-svn: 146897
|
| |
|
|
| |
llvm-svn: 146896
|
| |
|
|
|
|
| |
rdar://10602276
llvm-svn: 146895
|
| |
|
|
|
|
|
| |
direct-object emitter should emit the appropriate shift instruction depending
on the shift amount.
llvm-svn: 146893
|
| |
|
|
| |
llvm-svn: 146892
|
| |
|
|
| |
llvm-svn: 146889
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change reduces the number of instructions generated.
For example,
(load (add (sub $n0, $n1), (MipsLo got(s))))
results in the following sequence of instructions:
1. sub $n2, $n0, $n1
2. lw got(s)($n2)
Previously, three instructions were needed.
1. sub $n2, $n0, $n1
2. addiu $n3, $n2, got(s)
3. lw 0($n3)
llvm-svn: 146888
|
| |
|
|
| |
llvm-svn: 146887
|