| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
Goodbye code!
(Game: spot the bug fixed by the change).
llvm-svn: 206490
|
|
|
|
|
|
|
| |
These will be needed to support IR-level lowering of atomic
operations.
llvm-svn: 206489
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The commit of r205855:
Author: Arnold Schwaighofer <aschwaighofer@apple.com>
Date: Wed Apr 9 14:20:47 2014 +0000
SLPVectorizer: Only vectorize intrinsics whose operands are widened equally
The vectorizer only knows how to vectorize intrinics by widening all operands by
the same factor.
Patch by Tyler Nowicki!
exposed a backend bug causing a regression (Cannot select ctpop).
The commit msg is a bit confusing because the patch actually changes the
behavior for the loop-vectorizer as well. As things got refactored into a
helper ctpop got snuck in to the trivially-vectorizable helper which is now
used by both vectorizers. In other words, we started seeing vector-ctpops in
the backend.
This change makes ctpop LegalizeAction::Expand for the types not supported by
the byte-only CNT instruction. We may be able to custom-lower these later to
a single CNT but this is to fix the compiler crash first.
Fixes <rdar://problem/16578951>
llvm-svn: 206433
|
|
|
|
|
|
|
| |
I've left the MachO CodeGen as it is, there's a reasonable chance it should use
the GOT like ConstPools, but I'm not certain.
llvm-svn: 206288
|
|
|
|
|
|
|
| |
This brings it into line with the AArch64 behaviour and should open the way for
certain OpenCL features.
llvm-svn: 206286
|
|
|
|
|
|
|
| |
This transformation is only valid when being used for an EQ or NE
comparison since the flags change otherwise.
llvm-svn: 206167
|
|
|
|
| |
llvm-svn: 206006
|
|
|
|
|
|
| |
This is the second part of fixing PR19367.
llvm-svn: 205836
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were several overlapping problems here, and this solution is
closely inspired by the one adopted in AArch64 in r201381.
Firstly, scalarisation of v1i1 setcc operations simply fails if the
input types are legal. This is fixed in LegalizeVectorTypes.cpp this
time, and allows AArch64 code to be simplified slightly.
Second, vselect with such a setcc feeding into it ends up in
ScalarizeVectorOperand, where it's not handled. I experimented with an
implementation, but found that whatever DAG came out was rather
horrific. I think Hao's DAG combine approach is a good one for
quality, though there are edge cases it won't catch (to be fixed
separately).
Should fix PR19335.
llvm-svn: 205625
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous patterns directly inserted FMOV or INS instructions into
the DAG for scalar_to_vector & bitconvert patterns. This is horribly
inefficient and can generated lots more GPR <-> FPR register traffic
than necessary.
It's much better to emit instructions the register allocator
understands so it can coalesce the copies when appropriate.
It led to at least one ISelLowering hack to avoid the problems, which
was incorrect for v1i64 (FPR64 has no dsub). It can now be removed
entirely.
This should also fix PR19331.
llvm-svn: 205616
|
|
|
|
| |
llvm-svn: 205610
|
|
|
|
|
|
|
|
|
|
| |
Switching between i32 and i64 based on the LHS type is a good idea in
theory, but pre-legalisation uses i64 regardless of our choice,
leading to potential ISel errors.
Should fix PR19294.
llvm-svn: 205519
|
|
|
|
|
|
| |
This should fix PR19314.
llvm-svn: 205514
|
|
|
|
|
|
| |
No functional change.
llvm-svn: 205458
|
|
|
|
|
|
| |
No functional change intended.
llvm-svn: 205443
|
|
|
|
|
|
|
| |
We were creating libcall nodes that returned an MVT::f128, when these
particular operations actually return an int of some stripe.
llvm-svn: 205425
|
|
|
|
|
|
|
|
| |
Again, coalescing and other optimisations swiftly made the MachineInstrs
consistent again, but when compiled at -O0 a bad INSERT_SUBREGISTER was
produced.
llvm-svn: 205423
|
|
|
|
| |
llvm-svn: 205301
|
|
|
|
|
|
|
|
|
| |
is not a pattern to lower this with clever instructions that zero the
register, so restrict the zero immediate legality special case to f64
and f32 (the only two sizes which fmov seems to directly support). Fixes
backend errors when building code such as libxml.
llvm-svn: 205161
|
|
|
|
| |
llvm-svn: 205133
|
|
|
|
| |
llvm-svn: 205116
|
|
|
|
| |
llvm-svn: 205112
|
|
|
|
|
|
| |
Another existing bot failure so no tests.
llvm-svn: 205093
|
|
This adds a second implementation of the AArch64 architecture to LLVM,
accessible in parallel via the "arm64" triple. The plan over the
coming weeks & months is to merge the two into a single backend,
during which time thorough code review should naturally occur.
Everything will be easier with the target in-tree though, hence this
commit.
llvm-svn: 205090
|