| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 205013
|
|
|
|
|
|
|
|
|
| |
This reverts commit r204912, and follow-up commit r204948.
This introduced a performance regression, and the fix is not completely
clear yet.
llvm-svn: 205010
|
|
|
|
|
|
| |
Reviewed at http://llvm-reviews.chandlerc.com/D3095
llvm-svn: 205007
|
|
|
|
|
|
|
|
| |
This was causing my llc to go into an infinite loop on
CodeGen/R600/address-space.ll (just triggered recently by some allocator
changes).
llvm-svn: 205005
|
|
|
|
|
|
|
|
|
|
|
|
| |
As explained in r204976, because of how the allocation of VSX registers
interacts with the call-lowering code, we sometimes end up generating self VSX
copies. Specifically, things like this:
%VSL2<def> = COPY %F2, %VSL2<imp-use,kill>
(where %F2 is really a sub-register of %VSL2, and so this copy is a nop)
This adds a small cleanup pass to remove these prior to post-RA scheduling.
llvm-svn: 204980
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Construct a uniform Windows target triple nomenclature which is congruent to the
Linux counterpart. The old triples are normalised to the new canonical form.
This cleans up the long-standing issue of odd naming for various Windows
environments.
There are four different environments on Windows:
MSVC: The MS ABI, MSVCRT environment as defined by Microsoft
GNU: The MinGW32/MinGW32-W64 environment which uses MSVCRT and auxiliary libraries
Itanium: The MSVCRT environment + libc++ built with Itanium ABI
Cygnus: The Cygwin environment which uses custom libraries for everything
The following spellings are now written as:
i686-pc-win32 => i686-pc-windows-msvc
i686-pc-mingw32 => i686-pc-windows-gnu
i686-pc-cygwin => i686-pc-windows-cygnus
This should be sufficiently flexible to allow us to target other windows
environments in the future as necessary.
llvm-svn: 204977
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because of how the allocation of VSX registers interacts with the call-lowering
code, we sometimes end up generating self VSX copies. Specifically, things like
this:
%VSL2<def> = COPY %F2, %VSL2<imp-use,kill>
(where %F2 is really a sub-register of %VSL2, and so this copy is a nop)
The problem is that ExpandPostRAPseudos always assumes that *some* instruction
has been inserted, and adds implicit defs to it. This is a problem if no copy
was inserted because it can cause subtle problems during post-RA scheduling.
These self copies will have to be removed some other way.
llvm-svn: 204976
|
|
|
|
|
|
|
|
| |
in my previous commit (r204884).
<rdar://problem/16381225>
llvm-svn: 204972
|
|
|
|
|
|
|
|
|
| |
First, v2f64 vector extract had not been declared legal (and so the existing
patterns were not being used). Second, the patterns for that, and for
scalar_to_vector, should really be a regclass copy, not a subregister
operation, because the VSX registers directly hold both the vector and scalar data.
llvm-svn: 204971
|
|
|
|
|
|
|
|
| |
These operations need to be expanded during legalization so that isel does not
crash. In theory, we might be able to custom lower some of these. That,
however, would need to be follow-up work.
llvm-svn: 204963
|
|
|
|
| |
llvm-svn: 204961
|
|
|
|
| |
llvm-svn: 204956
|
|
|
|
|
|
|
| |
This allows 64-bit operations that are truncated to be reduced
to 32-bit ones.
llvm-svn: 204946
|
|
|
|
| |
llvm-svn: 204945
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
No functional change since these predicates are (currently) synonymous.
Extracted from a patch by David Chisnall
His work was sponsored by: DARPA, AFRL
Differential Revision: http://llvm-reviews.chandlerc.com/D3202
llvm-svn: 204943
|
|
|
|
|
|
|
|
| |
Lower SHL_PARTS, SRA_PARTS and SRL_PARTS to perform 128-bit integer shift
Patch by GuanHong Liu.
llvm-svn: 204940
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds back r204781.
Original message:
Aliases are just another name for a position in a file. As such, the
regular symbol resolutions are not applied. For example, given
define void @my_func() {
ret void
}
@my_alias = alias weak void ()* @my_func
@my_alias2 = alias void ()* @my_alias
We produce without this patch:
.weak my_alias
my_alias = my_func
.globl my_alias2
my_alias2 = my_alias
That is, in the resulting ELF file my_alias, my_func and my_alias are
just 3 names pointing to offset 0 of .text. That is *not* the
semantics of IR linking. For example, linking in a
@my_alias = alias void ()* @other_func
would require the strong my_alias to override the weak one and
my_alias2 would end up pointing to other_func.
There is no way to represent that with aliases being just another
name, so the best solution seems to be to just disallow it, converting
a miscompile into an error.
llvm-svn: 204934
|
|
|
|
|
|
|
|
|
|
|
|
| |
assertion.
Reviewers: matheusalmeida
Reviewed By: matheusalmeida
Differential Revision: http://llvm-reviews.chandlerc.com/D3201
llvm-svn: 204932
|
|
|
|
|
|
| |
with the definition, as well as to silence an MSVC C4099 warning).
llvm-svn: 204928
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Patch by Robert N. M. Watson
His work was sponsored by: DARPA, AFRL
Small corrections by myself.
CC: theraven, matheusalmeida
Differential Revision: http://llvm-reviews.chandlerc.com/D3199
llvm-svn: 204924
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on ABI rather than MIPS64
Summary: No functional change (for supported use cases)
Reviewers: matheusalmeida
Reviewed By: matheusalmeida
Differential Revision: http://llvm-reviews.chandlerc.com/D3191
llvm-svn: 204922
|
|
|
|
|
|
|
|
| |
Split the file MipsAsmBackend.h.
Differential Revision: http://llvm-reviews.chandlerc.com/D3134
llvm-svn: 204921
|
|
|
|
| |
llvm-svn: 204919
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of MCELFStreamer.
This is so that changes to MipsELFStreamer will automatically propagate through
its subclasses.
No functional changes (MipsELFStreamer has the same functionality of MCELFStreamer
at the moment).
Differential Revision: http://llvm-reviews.chandlerc.com/D3130
llvm-svn: 204918
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows us to insert some hooks before emitting data into an actual object file.
For example, we can capture the register usage for a translation unit by overriding
the EmitInstruction method. The register usage information is needed to generate
.reginfo and .Mips.options ELF sections.
No functional changes.
Differential Revision: http://llvm-reviews.chandlerc.com/D3129
llvm-svn: 204917
|
|
|
|
|
|
|
|
|
|
| |
Transform:
icmp X+Cst2, Cst
into:
icmp X, Cst-Cst2
when Cst-Cst2 does not overflow, and the add has nsw.
llvm-svn: 204912
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
isABI_N64() from MipsSubTarget in MipsTargetLowering
Summary:
The short name is quite convenient so provide an accessor for them instead.
No functional change
Depends on D3177
Reviewers: matheusalmeida
Reviewed By: matheusalmeida
Differential Revision: http://llvm-reviews.chandlerc.com/D3178
llvm-svn: 204911
|
|
|
|
|
|
| |
By Robert Khasanov rob.khasanov@gmail.com
llvm-svn: 204906
|
|
|
|
|
|
| |
cmake-llvm-x86_64-linux buildbot.
llvm-svn: 204901
|
|
|
|
|
|
|
|
|
|
|
| |
Fix description:
Expressions like 'cmp r0, #(l1 - l2) >> 3' could not be evaluated on asm parsing stage,
since it is impossible to resolve labels on this stage. In the end of stage we still have
expression (MCExpr).
Then, when we want to encode it, we expect it to be an immediate, but it still an expression.
Patch introduces a Fixup (MCFixup instance), that is processed after main encoding stage.
llvm-svn: 204899
|
|
|
|
|
|
| |
solved as a constant at compilation time.
llvm-svn: 204898
|
|
|
|
|
|
|
|
|
|
| |
and v4i64->v4f64.
The new costs match what we did for SSE2 and reflect the reality of our codegen.
<rdar://problem/16381225>
llvm-svn: 204884
|
|
|
|
|
|
|
|
| |
Fix the cost model to reflect the reality of our codegen.
rdar://16370633
llvm-svn: 204880
|
|
|
|
| |
llvm-svn: 204873
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vector list parameter that is using all lanes "{d0[], d2[]}" but can
match and instruction with a ”{d0, d2}" parameter.
I’m finishing up a fix for proper checking of the unsupported
alignments on vld/vst instructions and ran into this. Thus I don’t
have a test case at this time. And adding all code that will
demonstrate the bug would obscure the very simple one line fix.
So if you would indulge me on not having a test case at this
time I’ll instead offer up a detailed explanation of what is
going on in this commit message.
This instruction:
vld2.8 {d0[], d2[]}, [r4:64]
is not legal as the alignment can only be 16 when the size is 8.
Per this documentation:
A8.8.325 VLD2 (single 2-element structure to all lanes)
<align> The alignment. It can be one of:
16 2-byte alignment, available only if <size> is 8, encoded as a = 1.
32 4-byte alignment, available only if <size> is 16, encoded as a = 1.
64 8-byte alignment, available only if <size> is 32, encoded as a = 1.
omitted Standard alignment, see Unaligned data access on page A3-108.
So when code is added to the llvm integrated assembler to not match
that instruction because of the alignment it then goes on to try to match
other instructions and comes across this:
vld2.8 {d0, d2}, [r4:64]
and and matches it. This is because of the method
ARMOperand::isVecListDPairSpaced() is missing the check of the Kind.
In this case the Kind is k_VectorListAllLanes . While the name of the method
may suggest that this is OK it really should check that the Kind is
k_VectorList.
As the method ARMOperand::isDoubleSpacedVectorAllLanes() is what was
used to match {d0[], d2[]} and correctly checks the Kind:
bool isDoubleSpacedVectorAllLanes() const {
return Kind == k_VectorListAllLanes && VectorList.isDoubleSpaced;
}
where the original ARMOperand::isVecListDPairSpaced() does not check
the Kind:
bool isVecListDPairSpaced() const {
if (isSingleSpacedVectorList()) return false;
return (ARMMCRegisterClasses[ARM::DPairSpcRegClassID]
.contains(VectorList.RegNum));
}
Jim Grosbach has reviewed the change and said: Yep, that sounds right. …
And by "right" I mean, "wow, that's a nasty latent bug I'm really, really
glad to see fixed." :)
rdar://16436683
llvm-svn: 204861
|
|
|
|
|
|
|
| |
I've not yet updated PPCTTI because I'm not sure what the actual relative cost
is compared to the aligned uses.
llvm-svn: 204848
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
size 16 double-spaced registers instruction printing.
This:
vld4.16 {d17[1], d19[1], d21[1], d23[1]}, [r7]!
was being printed as:
vld4.16 {d17[1], d18[1], d19[1], d20[1]}, [r7]!
rdar://16435096
llvm-svn: 204847
|
|
|
|
| |
llvm-svn: 204843
|
|
|
|
|
|
| |
This sext_inreg i32 in i64 case was already handled, but not enabled.
llvm-svn: 204840
|
|
|
|
|
|
|
|
|
| |
These patterns are dead (because v4f32 stores are currently promoted to v4i32
and stored using Altivec instructions), and also are likely not correct
(because they'd store the vector elements in the opposite order from that
assumed by the rest of the Altivec code).
llvm-svn: 204839
|
|
|
|
|
|
|
|
| |
These instructions have access to the complete VSX register file. In addition,
they "swap" the order of the elements so that element 0 (the scalar part) comes
first in memory and element 1 follows at a higher address.
llvm-svn: 204838
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pointer" (r204174)
> For functions where esi is used as base pointer, we would previously fall ba
> from lowering memcpy with "rep movs" because that clobbers esi.
>
> With this patch, we just store esi in another physical register, and restore
> it afterwards. This adds a little bit of register preassure, but the more
> efficient memcpy should be worth it.
>
> Differential Revision: http://llvm-reviews.chandlerc.com/D2968
This didn't work. I was ending up with code like this:
lea edi,[esi+38h]
mov ecx,0Fh
mov edx,esi
mov esi,ebx
rep movs dword ptr es:[edi],dword ptr [esi]
lea ecx,[esi+74h] <-- Ooops, we're now using esi before restoring it from edx.
add ebx,3Ch
mov esi,edx
I guess if we want to do this we need stronger glue or something, or doing the expansion
much later.
llvm-svn: 204829
|
|
|
|
|
|
|
|
|
| |
v2i64 needs to be a legal VSX type because it is the SetCC result type from
v2f64 comparisons. We need to expand all non-arithmetic v2i64 operations.
This fixes the lowering for v2f64 VSELECT.
llvm-svn: 204828
|
|
|
|
|
|
|
|
| |
This enables TableGen to generate an additional two operand matcher
for our ArithLogicR class of instructions (constituted by 3 register operands).
E.g.: and $1, $2 <=> and $1, $1, $2
llvm-svn: 204826
|
|
|
|
|
|
|
| |
The '.dword' directive accepts a list of expressions and emits
them in 8-byte chunks in successive locations.
llvm-svn: 204822
|
|
|
|
|
|
|
|
|
|
|
|
| |
parseDirectiveWord is a generic function that parses an expression which
means there's no need for it to have such an specific name. Renaming it to
parseDataDirective so that it can also be used to handle .dword directives[1].
[1]To be added in a follow up commit.
No functional changes.
llvm-svn: 204818
|
|
|
|
|
|
|
|
|
|
| |
The '.set mips64' directive enables the feature Mips:FeatureMips64
from assembly. Note that it doesn't modify the ELF header as opposed
to the use of -mips64 from the command-line. The reason for this
is that we want to be as compatible as possible with existing assemblers
like GAS.
llvm-svn: 204817
|
|
|
|
|
|
|
|
|
|
| |
The '.set mips64r2' directive enables the feature Mips:FeatureMips64r2
from assembly. Note that it doesn't modify the ELF header as opposed
to the use of -mips64r2 from the command-line. The reason for this
is that we want to be as compatible as possible with existing assemblers
like GAS.
llvm-svn: 204815
|
|
|
|
| |
llvm-svn: 204814
|
|
|
|
|
|
|
|
|
| |
We've already got versions without the barriers, so this just adds IR-level
support for generating the new v8 ones.
rdar://problem/16227836
llvm-svn: 204813
|