| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
For ori, they are unsigned, for addi, signed. Create a new target
expression type to handle this and evaluate Fixups accordingly.
llvm-svn: 215315
|
|
|
|
|
|
|
| |
At least on PowerPC, the interpretation of certain modifiers depends on
the context they appear in.
llvm-svn: 215310
|
|
|
|
| |
llvm-svn: 215286
|
|
|
|
|
|
|
| |
since the operands are actually used on those cores. Provide aliases for
the only documented case in the newer Power ISA speec.
llvm-svn: 215282
|
|
|
|
| |
llvm-svn: 215281
|
|
|
|
|
|
| |
and update initialization.
llvm-svn: 215280
|
|
|
|
| |
llvm-svn: 215240
|
|
|
|
|
|
| |
empty functions will assert in the MC object writer.
llvm-svn: 215238
|
|
|
|
|
|
| |
soft-float is properly supported.
llvm-svn: 215221
|
|
|
|
| |
llvm-svn: 215220
|
|
|
|
|
|
|
|
|
|
|
| |
be deleted. This will be reapplied as soon as possible and before
the 3.6 branch date at any rate.
Approved by Jim Grosbach, Lang Hames, Rafael Espindola.
This reverts commits r215111, 215115, 215116, 215117, 215136.
llvm-svn: 215154
|
|
|
|
| |
llvm-svn: 215131
|
|
|
|
|
|
|
|
|
| |
I am sure we will be finding bits and pieces of dead code for years to
come, but this is a good start.
Thanks to Lang Hames for making MCJIT a good replacement!
llvm-svn: 215111
|
|
|
|
| |
llvm-svn: 215110
|
|
|
|
| |
llvm-svn: 215109
|
|
|
|
| |
llvm-svn: 215108
|
|
|
|
| |
llvm-svn: 215105
|
|
|
|
| |
llvm-svn: 215104
|
|
|
|
| |
llvm-svn: 215103
|
|
|
|
|
|
|
| |
them as parser-only until the disassembler is extended to handle
predicates properly.
llvm-svn: 215102
|
|
|
|
|
|
|
|
|
| |
to get the subtarget and that's accessible from the MachineFunction
now. This helps clear the way for smaller changes where we getting
a subtarget will require passing in a MachineFunction/Function as
well.
llvm-svn: 214988
|
|
|
|
| |
llvm-svn: 214929
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commits r213915 and r214718 fix recognition of shuffle masks for vmrg*
and vpku*um instructions for a little-endian target, by swapping the
input arguments. The vsldoi instruction requires similar treatment,
and also needs its shift count adjusted for little endian.
Reviewed by Ulrich Weigand.
This is a bug fix candidate for release 3.5 (and hopefully the last of
those for PowerPC).
llvm-svn: 214923
|
|
|
|
| |
llvm-svn: 214875
|
|
|
|
| |
llvm-svn: 214867
|
|
|
|
| |
llvm-svn: 214864
|
|
|
|
| |
llvm-svn: 214863
|
|
|
|
|
|
| |
for them.
llvm-svn: 214862
|
|
|
|
|
|
|
|
|
|
|
| |
shorter/easier and have the DAG use that to do the same lookup. This
can be used in the future for TargetMachine based caching lookups from
the MachineFunction easily.
Update the MIPS subtarget switching machinery to update this pointer
at the same time it runs.
llvm-svn: 214838
|
|
|
|
| |
llvm-svn: 214826
|
|
|
|
| |
llvm-svn: 214825
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
My original LE implementation of the vsldoi instruction, with its
altivec.h interfaces vec_sld and vec_vsldoi, produces incorrect
shufflevector operations in the LLVM IR. Correct code is generated
because the back end handles the incorrect shufflevector in a
consistent manner.
This patch and a companion patch for Clang correct this problem by
removing the fixup from altivec.h and the corresponding fixup from the
PowerPC back end. Several test cases are also modified to reflect the
now-correct LLVM IR.
llvm-svn: 214800
|
|
|
|
| |
llvm-svn: 214797
|
|
|
|
| |
llvm-svn: 214784
|
|
|
|
|
|
| |
information and update all callers. No functional change.
llvm-svn: 214781
|
|
|
|
| |
llvm-svn: 214769
|
|
|
|
|
|
| |
systems it represents.
llvm-svn: 214755
|
|
|
|
| |
llvm-svn: 214754
|
|
|
|
| |
llvm-svn: 214733
|
|
|
|
| |
llvm-svn: 214731
|
|
|
|
|
|
| |
Move the test cases for them into separate files.
llvm-svn: 214724
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In commit r213915, Bill fixed little-endian usage of vmrgh* and vmrgl*
by swapping the input arguments. As it turns out, the exact same fix
is also required for the vpkuhum/vpkuwum patterns.
This fixes another regression in llvmpipe when vector support is
enabled.
Reviewed by Bill Schmidt.
llvm-svn: 214718
|
|
|
|
|
|
|
|
|
|
| |
I ran into some test failures where common code changed vector division
by constant into a multiply-high operation (MULHU). But these are not
implemented by the back-end, so we failed to recognize the insn.
Fixed by marking MULHU/MULHS as Expand for vector types.
llvm-svn: 214716
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch refactors code generation of vector comparisons.
This fixes a wrong code-gen bug for ISD::SETGE for floating-point types,
and improves generated code for vector comparisons in general.
Specifically, the patch moves all logic deciding how to implement vector
comparisons into getVCmpInst, which gets two extra boolean outputs
indicating to its caller whether its needs to swap the input operands
and/or negate the result of the comparison. Apart from implementing
these two modifications as directed by getVCmpInst, there is no need
to ever implement vector comparisons in any other manner; in particular,
there is never a need to perform two separate comparisons (e.g. one for
equal and one for greater-than, as code used to do before this patch).
Reviewed by Bill Schmidt.
llvm-svn: 214714
|
|
|
|
| |
llvm-svn: 214640
|
|
|
|
| |
llvm-svn: 214639
|
|
|
|
|
|
|
|
|
| |
when let can do the same thing. Keep the 64bit variants as codegen-only.
While they have a different register class, the encoding is the same for
32bit and 64bit mode. Having both present would otherwise confuse the
disassembler.
llvm-svn: 214636
|
|
|
|
|
|
|
|
|
| |
so that we can use it to get the old-style JIT out of the subtarget.
This code should be removed when the old-style JIT is removed
(imminently).
llvm-svn: 214560
|
|
|
|
|
|
|
|
|
| |
Found by inspection while looking at PR20280: code would mark slots
in the parameter save area where a byval parameter is passed as
"immutable". This is not correct since code is allowed to modify
byval parameters in place in the parameter save area.
llvm-svn: 214517
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
regular loads
Altivec vector loads on PowerPC have an interesting property: They always load
from an aligned address (by rounding down the address actually provided if
necessary). In order to generate an actual unaligned load, you can generate two
load instructions, one with the original address, one offset by one vector
length, and use a special permutation to extract the bytes desired.
When this was originally implemented, I generated these two loads using regular
ISD::LOAD nodes, now marked as aligned. Unfortunately, there is a problem with
this:
The alignment of a load does not contribute to its identity, and SDNodes
are uniqued. So, imagine that we have some unaligned load, L1, that is not
aligned. The routine will create two loads, L1(aligned) and (L1+16)(aligned).
Further imagine that there had already existed a load (L1+16)(unaligned) with
the same chain operand as the load L1. When (L1+16)(aligned) is created as part
of the lowering of L1, this load *is* also the (L1+16)(unaligned) node, just
now marked as aligned (because the new alignment overwrites the old). But the
original users of (L1+16)(unaligned) now get the data intended for the
permutation yielding the data for L1, and (L1+16)(unaligned) no longer exists
to get its own permutation-based expansion. This was PR19991.
A second potential problem has to do with the MMOs on these loads, which can be
used by AA during instruction scheduling to break chain-based dependencies. If
the new "aligned" loads get the MMO from the original unaligned load, this does
not represent the fact that it will load data from below the original address.
Normally, this would not matter, but this load might be combined with another
load pair for a previous vector, and then the dependency on the otherwise-
ignored lower bytes can matter.
To fix both problems, instead of generating the necessary loads using regular
ISD::LOAD instructions, ppc_altivec_lvx intrinsics are used instead. These are
provided with MMOs with a conservative address range.
Unfortunately, I no longer have a failing test case (since PR19991 was
reported, other changes in CodeGen have forced this bug back into hiding it
again). Nevertheless, this should fix the underlying problem.
llvm-svn: 214481
|